Error Handling

n8n gives you several layers of error handling. Every workflow can call a separate Error Workflow when an execution fails, individual nodes can retry automatically or continue on failure, and executions can time out to stop runaway processes. Combined, these let you alert on failures, retry transient errors, degrade gracefully, or route failed items to a dead letter queue.

How do you run a workflow when another one fails?

Every workflow can designate a separate Error Workflow that runs whenever an execution fails. Configure it in Workflow Settings > Error Workflow.

The error workflow receives an execution object containing:

• The ID of the failed execution.
• The error message and stack trace.
• The name of the node that failed.

Use the error workflow to send Slack alerts, create tickets, or log failures to an external system.

Note

The error workflow must use an Error Trigger node as its starting node. A single error workflow can serve multiple production workflows.

The Error Trigger node fires when an execution in a linked workflow fails. Access the error details through its output:

{{ $json.execution.id }}
{{ $json.execution.error.message }}
{{ $json.execution.error.node.name }}
{{ $json.workflow.name }}

How do you handle errors on individual nodes?

Individual nodes can be configured to retry automatically when they fail:

1. Open the node's Settings tab.
2. Enable Retry on Fail.
3. Set Max Retries (number of additional attempts).
4. Set Wait Between Retries (milliseconds between attempts).

Tip

Use retry on fail for nodes calling unreliable APIs or services prone to transient errors (rate limits, timeouts). Set a reasonable wait between retries to avoid hammering the service.

When Continue on Fail is enabled in a node's settings, the workflow continues executing even if that node errors. The failed node outputs the error information instead of the expected data:

{
  "json": {
    "error": "Request failed with status 404"
  }
}

Downstream nodes can check for the presence of an error field and branch accordingly using an IF node.

Warning

Use Continue on Fail deliberately. If enabled carelessly, downstream nodes may receive unexpected data and produce silent failures.

Set a maximum duration for workflow executions to prevent runaway processes:

• Instance-level -- environment variable EXECUTIONS_TIMEOUT (seconds). Applies to all workflows.
• Workflow-level -- override in Workflow Settings > Execution Timeout. Set a shorter or longer limit for a specific workflow.

When a timeout is reached, the execution is marked as failed and the error workflow (if configured) is triggered.

What are the common error-handling patterns?

Pattern	Implementation
Alert on failure	Error workflow sends a Slack message or email with error details
Retry then alert	Enable Retry on Fail on the node; use an error workflow as a fallback
Graceful degradation	Enable Continue on Fail, then use an IF node to check for errors and take an alternative path
Dead letter queue	Error workflow writes the failed item data to a database or queue for later reprocessing

Setting	Scope	Location
Error Workflow	Workflow	Workflow Settings
Retry on Fail	Node	Node Settings tab
Continue on Fail	Node	Node Settings tab
Execution Timeout	Instance or Workflow	Environment variable or Workflow Settings

Related: Workflows and Executions · Nodes