Error Handling in n8n: A Practical Guide
n8n handles errors through three main mechanisms: per-node On Error settings that control whether a failed node stops or continues the workflow, retry logic that automatically retries failed nodes a set number of times, and error workflows that run automatically when a production workflow fails. For production workflows, set up a dedicated error workflow that sends a notification with the workflow name, node name, and error message. This ensures failures are visible rather than silent.
n8n has built-in error handling through the Error Trigger node, retry settings, and error workflows that run when a production workflow fails.
Why error handling matters in production
Workflows that run without monitoring create invisible failures. An API rate limit hit at 3am, a changed response format from an external service, or a missing field in incoming data can silently break your automation for hours or days without anyone noticing. Good error handling converts silent failures into visible notifications you can act on.
n8n provides several layers for handling errors, from fine-grained per-node control to workflow-level error routing. Understanding all three mechanisms lets you build reliable automations that degrade gracefully when things go wrong. For context on n8n basics, see our article on what n8n is and creating your first n8n workflow.
Step 1: Understand stop-on-error vs continue
Every node in n8n has an On Error setting accessible in the node’s settings panel. Three options are available:
- Stop Workflow Execution: the default. When this node fails, the workflow halts and the execution is marked as failed.
- Continue (ignoring error): the failed item is skipped and execution moves to the next item. Use this when processing lists where some failures are expected and acceptable.
- Continue (using error output): the node exposes a red error connector. Failed items flow through this connector to a separate branch you define, while successful items continue through the normal path.
The right choice depends on the situation. For a node calling a critical API, stop-on-error makes sense because proceeding with bad data may cause worse problems downstream. For a node enriching data where some items legitimately have no match, continue-ignoring makes more sense.
Step 2: Add an Error Trigger workflow
Create a new workflow in n8n and add an Error Trigger as the first node. This workflow will automatically run whenever a linked production workflow fails.
Connect the Error Trigger to notification nodes. The Error Trigger provides context including:
execution.workflowData.name: the name of the failed workflowexecution.error.message: the error messageexecution.error.node.name: the name of the node that failedexecution.id: the execution ID (useful for finding it in the executions panel)
Use a Send Email node or a messaging node (Slack, Teams) to send these details to the relevant person. A message like “Workflow X failed at node Y: Z” gives you enough context to diagnose the problem quickly.
Step 3: Link the error workflow to your production workflow
Open your production workflow and go to its settings panel. Find the Error Workflow field and select the error notification workflow you created. Save the workflow.
Now when this production workflow encounters an unhandled error, n8n automatically triggers the error workflow. You can use a single shared error workflow across all your production workflows, or create separate ones for different teams or severity levels.
Step 4: Configure retry logic
For nodes that call external APIs, open the node settings and enable Retry On Fail. Set the number of attempts (typically 2 or 3) and the wait interval between attempts (typically 5 to 30 seconds). This handles transient failures automatically: temporary API unavailability, rate limiting, or network timeouts that resolve on their own.
Do not set retry counts too high for nodes writing data. Retrying a POST request that creates a record might create duplicates if the first request succeeded but the response was lost.
Step 5: Use the error output connector
When a node is set to Continue (using error output), a red error connector appears on the node. Connect this to subsequent nodes to handle the error inline. A common pattern is:
- Node fails, routes to error output
- A Set node formats an error object with the failed item and error message
- The formatted error is written to a log table or sent to a notification channel
This lets you handle errors within the same workflow without needing a separate error workflow. It is particularly useful for batch processing workflows where you want to collect all failures and report them in a single summary at the end.
Step 6: Test your error handling
Before considering a workflow production-ready, deliberately trigger a failure and verify that your error handling works. Point a node at an invalid URL, remove a required field, or introduce a syntax error in a Code node. Confirm that the error workflow fires, the notification arrives, and the message contains useful information.
Our tip: Always include the execution URL in your error notifications. n8n’s Error Trigger provides the execution ID, which you can use to construct a direct link to the failed execution in the n8n UI. This saves significant time when diagnosing what went wrong.
Frequently asked questions
What is the Error Trigger node in n8n?
The Error Trigger node is a special trigger that fires when another workflow fails. You create a separate workflow that starts with an Error Trigger, add notification steps (email, Slack, etc.), and then link your production workflows to this error workflow in their settings. When a production workflow encounters an unhandled error, n8n automatically calls the error workflow and passes context including the workflow ID, execution ID, node name, and error message.
What is the difference between stop-on-error and continue in n8n?
Stop Workflow Execution is the default behaviour: when a node fails, the entire workflow halts and the execution is marked as failed. Continue (ignoring error) skips the failed item and moves on, which is useful when processing lists where some items may legitimately fail. Continue (using error output) sends the failed item through a separate error branch you define, giving you full control over what happens to failed items without stopping the whole workflow.
How do I get notified when an n8n workflow fails?
Create a dedicated error workflow with an Error Trigger node followed by a notification node, such as the Send Email node or a Slack or Teams message node. Include the error context fields that the Error Trigger provides: workflow name, node name, error message, and execution URL. Then link each production workflow to this error workflow in the workflow's settings under Error Workflow. You can use one shared error workflow for all your production workflows.