Handle errors

What you'll build: A workflow that routes a failing node to a separate path, logs the failure with useful context, retries transient failures where it makes sense, and terminates cleanly when the error is unrecoverable. After this guide, you'll have a pattern you can drop into any existing workflow.

What you'll need

• A UiPath Automation Cloud account with access to Maestro Flow.
• An existing Flow workflow with at least one node that can fail and exposes an error handle — for example, an HTTP Request or an Extract node.

Nodes used

• HTTP Request — the failure-prone node in this example
• Script — logs the error details
• Terminate — ends the workflow with a Failed status on unrecoverable errors

Steps

1. Connect the node's error handle

By default, a failed node stops the entire process. To handle the failure instead:

1. Open your workflow on the canvas and select the failure-prone node.
2. Drag from its error handle — the connector on the bottom-right of the node — to a new Script node.

This creates an error path. When the node fails, execution routes along this path instead of stopping the process. (Nodes that don't expose an error handle don't support error handling — a failure there stops the process and surfaces under the Incidents tab.)

2. Log the error

In the Script node on the error path, read the error object at $vars.<node>.error:

const error = $vars.httpRequest1.error;
console.log('Step failed:', error.message);
console.log('Code:', error.code, '| HTTP status:', error.status);
return { logged: true };

The error object is only populated on the error path. For its full field reference, see Error handling.

3. Retry transient failures (optional)

If the failure is likely transient — a network blip or a rate limit — retry before giving up. The HTTP Request node has built-in retries: configure the retry count in its properties, and it re-attempts the request that many times before triggering the error handle. Only the final failure routes to the error path.

Warning:

Retry only idempotent operations. Retrying a node with side effects (writing data, sending a message) can create duplicates.

4. Terminate if unrecoverable

On the error path, after the Script node, add a Terminate node. Set:

• Status → Failed
• Message → a description that includes the error, for example $vars.httpRequest1.error.message

This records the failure in the execution history with a useful description, visible in Observing runs.

5. Test and debug

To trigger the error path intentionally:

1. Temporarily set the URL in the HTTP Request node to an invalid value (for example, https://this-will-fail.example.com).
2. Run the test and verify the execution trace routes along the error path.
3. Restore the correct URL.

Check the Script node's console output in the trace to confirm the error details are logged.

Result

Your workflow routes failures to the error path, logs the error details, optionally retries transient failures, and terminates cleanly with a descriptive failure status. You can confirm the error path works by using an invalid URL in the HTTP Request node and inspecting the Script node's console output in the execution trace.

Extend this workflow

• Send an alert on failure — On the error path, before the Terminate node, add an HTTP Request or integration node to notify a Slack channel or create an incident ticket.
• Continue instead of terminating — If the step is non-critical, have the error path set a fallback value and rejoin the main path instead of terminating.
• Apply this pattern everywhere — For more patterns (log and continue, fallback values, escalation), see the Error handling reference.