Learn › n8n Foundations: From Zero to First Automation › Error Handling: Workflows That Don't Silently Fail

Error Handling: Workflows That Don't Silently Fail

Beginner 🕐 12 min Lesson 13 of 15
What you'll learn
  • Configure per-node retry logic with appropriate max tries and wait times
  • Create an error workflow with an Error Trigger node to receive failure notifications
  • Use Continue On Error to keep a workflow running past individual item failures

The Silent Failure Problem

An automation that fails and tells you about it is infinitely more valuable than one that fails silently. Production workflows deal with flaky APIs, expired credentials, malformed data, and network timeouts. Without explicit error handling, these failures disappear — your CRM never gets updated, your customer never gets their email, and you only find out days later when someone complains.

n8n provides two layers of error handling: per-node retry settings for transient failures, and error workflows for unrecoverable failures.

Per-Node Retry Logic

On any node, open its settings (the three-dot menu → Settings) and find Retry On Fail. Enable it and set:

  • Max Tries — how many times to retry (2–3 is a reasonable default)
  • Wait Between Tries — seconds to wait between attempts. Use exponential backoff mentally: wait 1s, then 5s, then 30s.

Retry is ideal for HTTP Request nodes calling external APIs, database nodes that may experience connection timeouts, and any node interacting with a service that has intermittent availability. Do not use it for credential errors or 4xx responses — those won't succeed on retry.

Error Workflows

An error workflow is a separate workflow that n8n automatically triggers when your main workflow fails with an uncaught error. It receives detailed context about the failure: the workflow name, the node that failed, the error message, and the execution ID.

To set up an error workflow:

  1. Create a new workflow that starts with the Error Trigger node
  2. Add your notification logic: send yourself a Slack message, create a Jira issue, send an email with the error details
  3. Go back to your main workflow → Settings → Error Workflow → select the error workflow you just created

A useful Slack notification in the error workflow:

Workflow {{ $json.workflow.name }} failed at node {{ $json.execution.lastNodeExecuted }}: {{ $json.execution.error.message }}

Continue on Error

Sometimes you want a workflow to keep running even when one node fails — for example, if one of 100 email sends fails, you don't want to abort the other 99. On any node, go to Settings → Continue On Error. When enabled, failed items pass to the next node with an error flag, and the workflow finishes. You can then use an IF node to check for {{ $json.error }} and handle failed items separately.

The Execution Log

Every n8n workflow run is stored in the Executions tab. Click any execution to replay it step by step and see exactly what data entered and exited each node. When debugging a failure, the execution log is your first stop — it shows the precise error message, the node that threw it, and the data that caused it.

Key takeaways
  • Per-node Retry On Fail handles transient failures — set 2-3 max tries; retry is useless for 4xx errors or credential failures
  • An error workflow is a separate workflow triggered automatically when the main workflow fails — connect it in Settings → Error Workflow for every production automation
  • The Executions tab stores every run with full node-by-node data — always check it first when debugging a failure