n8n Error Handling

Production n8n workflows fail. APIs return errors, data arrives in unexpected formats, services have downtime. Workflows without proper error handling fail silently — data is lost, processes are skipped, and nobody knows until a customer complains. This guide covers n8n's error handling tools and patterns for building automation that fails gracefully.

MJK Supplies · Jan 13, 2026 · 4 min read

ShareX in f ↗

Types of Failures in n8n Workflows

Node execution errors: A node fails to execute — usually because the target API returned an error, authentication failed, or the node received data in an unexpected format.

Data validation errors: The data from a previous node doesn't match what the current node expects — a field is missing, a value is in the wrong format, or an array is empty when the node expects at least one item.

Timeout errors: A node or external API call takes too long and exceeds the configured timeout.

Rate limit errors: An API returns a 429 (Too Many Requests) error because the workflow is calling it too frequently.

Silent failures: The worst kind — the workflow appears to succeed but produces wrong results. AI returns unexpected output format, data is written to the wrong field, or an optional step fails without marking the workflow as failed.

Basic Error Handling: Try/Catch Patterns

n8n's most basic error handling: every node has a "Continue on Fail" option and "Error Output" toggle.

Continue on Fail: When enabled, if this node fails, the workflow continues to the next node rather than stopping. The failed execution's data is still available. Use this for optional steps — steps where failure is acceptable.

Error Output: When enabled, a node gets two output connectors: one for success, one for failure. You can route these to different subsequent nodes — handling success and failure paths independently. This is the recommended approach for any node where failure needs specific handling (logging, alerting, retry).

Example: an HTTP Request node calling an external API has two paths. Success path: continue to data processing. Error path: log the error to Airtable, send a Slack alert, and stop.

The Error Trigger Node

For workflow-level error handling, the Error Trigger node fires when any other workflow fails. Create a dedicated error handling workflow:

Add an Error Trigger node
The trigger automatically includes data about the failed workflow: which workflow, which node, the error message, and the execution ID
Add nodes to log the error, send an alert, and optionally retry

In the failing workflow's settings, set "Error Workflow" to your error handling workflow. When any execution of the workflow fails, the error workflow fires automatically.

This is the recommended pattern for production workflows — centralised error handling rather than error handling in every workflow.

Retry Logic

Some failures are transient — API rate limits, temporary network issues, service hiccups. Retry logic handles these automatically without manual intervention.

n8n's built-in retry: in node settings, enable "Retry on Fail" and set the number of retries and wait interval. This is simple and sufficient for most cases.

For custom retry logic with exponential backoff (increasing wait time between retries):

// Code node - exponential backoff retry const maxRetries = 5; const attempt = $input.first().json.attempt || 0; if (attempt >= maxRetries) { throw new Error(`Max retries exceeded after ${maxRetries} attempts`); } // Calculate delay: 2^attempt seconds (1s, 2s, 4s, 8s, 16s) const delayMs = Math.pow(2, attempt) * 1000; await new Promise(resolve => setTimeout(resolve, delayMs)); return [{ json: { ...items[0].json, attempt: attempt + 1 } }];

Dead Letter Queue Pattern

Items that fail repeatedly — after all retries — should not be silently dropped. A dead letter queue captures them for manual review.

The pattern:

Workflow processes items normally
On error, route to the retry logic with retry count increment
After max retries, route to an Airtable (or Google Sheet) "failed items" table
The Airtable record includes: the original input data, the error message, the timestamp, and a "processed" flag
A human reviews the failed items periodically and re-processes or resolves them

This ensures no data is ever silently lost — failed items are always recoverable.

Monitoring and Alerting

Build monitoring into every production workflow:

Execution logging: For any important workflow, add a "success log" step at the end that writes execution metadata to Airtable — workflow name, input summary, output summary, execution time, status. This creates an audit trail.

Slack alerting: Wire up the Error Trigger to send a Slack message for every workflow failure. Include: workflow name, error node, error message, and a link to the execution in n8n.

Volume monitoring: For high-volume workflows (processing many items daily), add a check that validates expected execution counts. If a workflow that normally processes 200 items per day processed only 5, that's an anomaly worth alerting on even if no individual execution failed.

Webhook response monitoring: For workflows triggered by webhooks, monitor that webhooks are arriving at the expected rate. A sudden drop in webhook events (to zero) often indicates the sending service's webhook configuration broke, not n8n itself.