n8n Error Handling: Error Trigger, Error Workflow, and HTTP Retries

Why n8n Error Handling Matters

A workflow that runs perfectly in testing will eventually fail in production — an API returns a 429, a downstream service is temporarily down, or a record arrives in an unexpected format. Without deliberate error handling, n8n marks the execution as failed, stops processing, and does nothing. Items that were mid-flight are lost, and you find out only when you happen to check the execution log.

n8n provides three layers to address this: retry at the HTTP level (for transient failures), Continue on Fail at the node level (for inline error handling), and error workflows triggered by the Error Trigger node (for centralized alerting and cleanup). Each has a distinct job.

Layer 1 — HTTP Request Retries

The simplest form of error handling is automatic retry on the HTTP Request node. When an API call fails with a network error, a 429, or a 5xx response, n8n can retry the same request automatically before the workflow fails.

How to enable it

In any HTTP Request node, click the Options tab and toggle Retry On Fail to on. Two settings appear:

• Max Tries — how many attempts in total (the original plus retries). Default is 3; max is 5.
• Wait Between Tries (ms) — how long to pause between attempts. Default is 1000 ms.

Retries only fire on failed requests — HTTP errors (non-2xx that n8n interprets as failures) or network-level timeouts. A 200 response with an error payload in the body will not trigger a retry; you need node-level logic for that case.

Exponential backoff with a loop

When you need more control — such as exponential backoff or retry-only-on-specific-codes — build a manual retry loop:

1. Add a Loop Over Items node around your HTTP Request.
2. After the HTTP Request, add an IF node checking {{ $response.statusCode }}.
3. On the failure branch, add a Wait node (set duration with an expression to double each attempt) then route back into the loop.
4. Use a counter stored in Set node data to break the loop after N attempts.

This pattern gives you full control over retry conditions and intervals at the cost of a more complex workflow structure.

Layer 2 — Continue on Fail (Inline Try/Catch)

The HTTP retry layer only handles network calls. For other node types — database queries, code nodes, external service nodes — you need a different approach.

Continue on Fail is n8n's equivalent of a try/catch block. When enabled on a node, a failure does not stop the execution. Instead, n8n passes the failed item downstream with an error property attached, and the workflow continues.

How to enable it

Select any node, open its Settings tab, and toggle Continue on Fail to on. You will also see two sub-options:

• Use Input Data — pass the original input item downstream (useful when you want to log what was being processed when it failed).
• Add Error to Output — attach the error message to the output item as a JSON property.

Enable both in most cases. The downstream IF node then checks for the error property to route failed items to an error branch.

The pattern

[ Risky Node (Continue on Fail ON) ]
         ↓
[ IF: {{ $json.error !== undefined }} ]
   true  →  [ Error Branch: log / alert / dead-letter queue ]
   false →  [ Normal Branch: continue processing ]

This lets you handle specific node failures gracefully — log them, write to a dead-letter Airtable, or send a targeted Slack message — without sending the entire workflow to a global error handler.

Layer 3 — Error Trigger and Error Workflows

The Error Trigger is n8n's global error handler. It fires automatically when any workflow that has designated an error workflow fails completely — meaning the execution stopped with an error that was not caught at the node level.

What the Error Trigger receives

When triggered, it provides a structured payload you can reference with {{ $json }}:

• execution.id — the failed execution ID
• execution.url — direct link to the failed run in the n8n UI
• execution.workflowId and execution.workflowName
• execution.mode — how it was triggered (webhook, trigger, manual, etc.)
• error.message — the error text
• error.description — additional detail if available
• error.timestamp — when the error occurred
• error.node.name — which node failed

These fields let you build a Slack alert that reads: "Workflow 'Stripe → QBO Sync' failed at node 'Create QBO Invoice' — Cannot read customer ID. View execution →"

Setting up an error workflow

1. Create a new workflow — name it something like "Global Error Handler".
2. Add the Error Trigger node as the first node (it is under Triggers → n8n).
3. Connect a Slack node (or email/HTTP Request) to the Error Trigger. In the message body, use expressions like {{ $json.execution.workflowName }}, {{ $json.error.message }}, and {{ $json.execution.url }} to build an actionable alert.
4. Activate the error workflow.
5. In each workflow you want to monitor, go to Settings → Error Workflow and select your Global Error Handler.

A minimal Slack alert

In your Slack node, set the channel and use this message body:

:red_circle: *n8n Workflow Failed*
*Workflow:* {{ $json.execution.workflowName }}
*Node:* {{ $json.error.node.name }}
*Error:* {{ $json.error.message }}
*Time:* {{ $json.error.timestamp }}
<{{ $json.execution.url }}|View execution →>

This gives whoever is on-call a clickable link directly to the failed execution, with enough context to act immediately.

Protecting Batch Workflows from Partial Failures

When a workflow processes a large list of items — syncing 5,000 orders from an API, for example — a single failure in the middle of the list stops all remaining items. You lose progress and have no easy way to resume.

The fix is to combine small batches with the Loop Over Items node and an external checkpoint:

1. Use Loop Over Items to process records in batches of 50–200.
2. After each batch completes successfully, write the last processed ID (or offset) to a persistent store — an Airtable row, a Postgres table, or n8n's static workflow data via $getWorkflowStaticData('global').
3. At the start of each run, read the checkpoint and resume from where you left off.

A failure in batch 12 of 100 means you only lose that batch, not all remaining 88. On the next scheduled run, the workflow reads the checkpoint and resumes at batch 13.

Using n8n static data as a checkpoint store

// In a Code node — read last offset
const state = $getWorkflowStaticData('global');
const lastId = state.lastProcessedId || 0;
return [{ json: { lastId } }];

// After each batch — write new offset
const state = $getWorkflowStaticData('global');
state.lastProcessedId = items[items.length - 1].json.id;
return items;

Static workflow data persists between executions and does not require any external database.

Choosing the Right Layer for Each Situation

A well-built n8n workflow uses all three layers in combination. Here is a practical decision guide:

• Transient API errors (429, 503, network blip) → HTTP Request retry. Set 3–5 tries with 2–5 second intervals.
• Expected-but-recoverable failure on a specific node (record not found, validation error on one item in a batch) → Continue on Fail + IF node. Handle inline; do not surface as a global alert.
• Unexpected failures that require human attention → let the workflow fail, let the Error Trigger fire, send a Slack alert with execution link.
• Long batch jobs where partial failure is acceptable → Loop Over Items + checkpoint pattern. Only global-alert if the checkpoint is not updated for N consecutive runs.

Common Mistakes

• Putting Continue on Fail on every node — this silences all errors. If nothing alerts, you end up with silent data loss. Use it selectively on nodes where failure is expected for some items.
• Forgetting to activate the error workflow — an inactive error workflow will not run. The Error Trigger only fires in activated workflows.
• Linking a workflow to itself as its error handler — causes an infinite loop. The error workflow must be a separate workflow.
• Using retries on non-idempotent requests — retrying a POST that creates a record will create duplicates. Add idempotency keys (like a Payment Intent ID or external reference ID) before enabling retries on write endpoints.

Summary

n8n error handling works in three layers. HTTP retries handle transient network failures automatically. Continue on Fail with an IF node handles expected per-item failures inline without stopping the workflow. The Error Trigger and error workflow handle unexpected workflow-level failures with centralized alerting. For batch jobs, combine Loop Over Items with a checkpoint pattern to make large processing jobs resumable on failure.

For production n8n deployments, we recommend setting an error workflow on every active workflow from day one. It costs nothing and means you learn about failures immediately rather than when a customer complains.

If you want help building resilient n8n pipelines with proper error handling and monitoring, see how Entech builds production-grade multi-system orchestration or contact us to talk through your workflow architecture.