# Error handling

> Per-node error handles in Flow that route node failures to a separate path and expose error details through variables.

## What it is

Error handling in Flow is a per-node mechanism that lets you control what happens when a node fails during execution. By default, a failed node stops the entire process. You can override this by connecting an error handle to route failures to a separate path where you inspect and respond to the error.

## How it works

Every node that supports error handling has an error handle — an output connector on the bottom-right of the node that activates when the node fails. Not all nodes support error handling; only those with the `supportsErrorHandling` flag expose an error handle.

When a node with a connected error handle fails, execution routes to the error path instead of stopping the process. The error details become available as a variable you can read in downstream nodes.

When a node without a connected error handle fails, the entire process fails immediately. The error surfaces in the execution panel under the **Incidents** tab.

![Two HTTP Request nodes side by side: one with its error handle connected to a downstream Script node, and one with the error handle unconnected.](https://dev-assets.cms.uipath.com/assets/images/maestro/flow-error-handling-f62e6faf.webp)

### HTTP Request retries

The HTTP Request node supports configurable retries. When retries are configured, the node attempts the request the specified number of times before triggering the error handle. If all retries fail and an error handle is connected, execution routes to the error path. If no error handle is connected, the process fails.

## Configuring error handles

An error handle is wired by connecting the node's error handle connector (bottom-right corner) to another node on the canvas. A node without an error handle connector does not support error handling, so any failure stops the process.

![HTTP Request node on the canvas with its error handle connector visible and an edge connecting it to a downstream Script node.](https://dev-assets.cms.uipath.com/assets/images/maestro/flow-error-handle-visible-8840a2f6.webp)

## The error object

When an error handle is connected and the node fails, the error details are available as `$vars.<nodeName>.error`. This object has the following fields:

### code

A machine-readable error code identifying the type of failure.

### message

A human-readable description of what went wrong. Use this for logging or displaying error information.

### detail

A detailed technical description of the failure, including stack traces or service-specific information when available.

### category

The error category, grouping related error types.

### status

The HTTP status code associated with the error. Populated for HTTP-related failures (for example, `404` or `500`).

The error object is only available on the error path. Accessing `$vars.<nodeName>.error` on the success path returns undefined.

## Practical example

This example uses an HTTP Request node to call an external API, with a Script node on the error path that logs the failure.

An **HTTP Request** node is placed on the canvas and configured with the target URL. Its error handle is connected to a **Script** node. The Script node reads the error object as follows:

```javascript
const error = $vars.httpRequest1.error;
return {
  failed: true,
  reason: error.message,
  httpStatus: error.status,
  detail: error.detail
};
```

![Canvas showing an HTTP Request node with a success path connected to a Script node and an error path connected to Script 2. The Script 2 properties panel shows the error-logging code.](https://dev-assets.cms.uipath.com/assets/images/maestro/flow-success-error-path-e7a2bc15.webp)

When the HTTP request succeeds, execution follows the success path and the Script node is skipped. When the request fails (after any configured retries), execution routes to the Script node, which receives the full error object.

## Patterns

These are common approaches to handling, logging, retrying, and escalating errors. They all build on the per-node error handle described above: a connected error handle routes failures to a separate path, where the error object is available at `$vars.<node>.error`.

### Log and continue

This pattern fits non-critical operations where the workflow should continue even if one step fails. The node's error handle connects to a **Script** node that logs the error, then rejoins the main path so execution continues.

```javascript
// Script node on the error path
console.log('Non-critical step failed:', $vars.step1.error.message);
return null; // downstream nodes handle null gracefully
```

### Retry with limit

This pattern fits likely transient failures such as network timeouts, rate limits, or temporary service outages. For the **HTTP Request** node, the built-in retry count re-attempts the request before triggering the error handle, and only the final failure routes to the error path. Retry settings belong only on idempotent operations.

### Alert and terminate

This pattern fits unrecoverable errors that require human attention. On the error path, a notification is sent (via an HTTP Request or integration node), then a **Terminate** node with status `Failed` and a descriptive message such as `$vars.step1.error.message` ends the workflow.

### Fallback value

This pattern fits operations that may fail but have a safe default value that allows the workflow to continue meaningfully. On the error path, a **Script** node sets the expected output to a default value, then rejoins the main path as if the operation had succeeded.

### Common mistakes

- **Swallowing errors silently** — Errors on the error path should always be logged, even when the workflow continues. Silent failures are hard to diagnose later.
- **Retrying non-idempotent operations** — Operations with side effects (writing data, sending a message) may produce duplicates if retried. Retry settings belong only on operations that can run more than once without creating duplicates.
- **Leaving error handles unconnected** — A node whose error handle isn't connected fails the entire process on error. Workflows that should continue past a failure need a connected error path.

## Related pages

- **[Handle errors](handle-errors-gracefully.md)** — step-by-step task: build an error path end to end
- **[The canvas](canvas-overview.md)** — overview of the workspace including the execution panel
- **[Variables and data flow](variables-and-data-flow.md)** — how data passes between nodes using `$vars`
- **[Debugging effectively](debugging-effectively.md)** — tips for inspecting errors in Debug mode