Back to n8n Fundamentals
n8n Fundamentals

How to Handle Errors in n8n

Error handling nodes, retry logic, error output routing to exception queue.

How to Handle Errors in n8n

Workflows fail. APIs

timeout. Rate limits hit. Your job is to catch these failures before they cascade into data loss or silent corruption.

n8n provides three error handling mechanisms: node-level error outputs, workflow-level error triggers, and built-in retry logic. This guide shows you exactly how to configure each one.

Node-Level Error Handling

Every node in n8n has two outputs: success and error. Most users ignore the error output. Don't.

Configure Error Output on Any Node:

  1. Click the node you want to monitor
  2. Open Settings (gear icon)
  3. Scroll to "On Error" section
  4. Select "Continue on Fail"
  5. Connect the error output (red dot) to your error handler

When "Continue on Fail" is enabled, the node outputs error data instead of stopping the workflow. The error output contains:

  • error.message - Human-readable error description
  • error.stack - Full stack trace
  • error.httpCode - Status code (for HTTP nodes)
  • error.cause - Original error object

Example: Route Failed API Calls to Slack

Connect your HTTP Request node's error output to a Slack node:

Slack Message Template:
API call failed: `{{$node["HTTP Request"].json.error.message}}`
Endpoint: `{{$node["HTTP Request"].parameter.url}}`
Status: `{{$node["HTTP Request"].json.error.httpCode}}`
Time: `{{$now}}`

This pattern works for any node. The error output always contains the full context of what failed and why.

Workflow-Level Error Triggers

The Error Trigger node catches any unhandled error in the entire workflow. Use this as your safety net when individual node error handling isn't enough.

Set Up a Global Error Handler:

  1. Add "Error Trigger" node to your canvas
  2. Position it away from your main workflow (visual clarity)
  3. Set "Workflow Errors" to "All Errors"
  4. Connect to your notification or logging system

The Error Trigger receives:

  • execution.id - Unique execution identifier
  • execution.mode - Manual, trigger, or webhook
  • execution.error.node - Which node failed
  • execution.error.message - Error details
  • execution.data - Full workflow state at failure

Example: Log All Errors to Airtable

Create an "Error Log" base in Airtable with these fields:

  • Workflow Name (text)
  • Error Node (text)
  • Error Message (long text)
  • Timestamp (datetime)
  • Execution ID (text)

Connect your Error Trigger to an Airtable node:

Workflow Name: `{{$workflow.name}}`
Error Node: `{{$json.execution.error.node}}`
Error Message: `{{$json.execution.error.message}}`
Timestamp: `{{$now}}`
Execution ID: `{{$json.execution.id}}`

Now every workflow failure writes to your central error log. Filter by workflow name to identify problematic integrations.

Built-In Retry Logic

Transient failures (network blips, temporary API

unavailability) shouldn't kill your workflow. Configure automatic retries at the node level.

Enable Retries on HTTP Request Nodes:

  1. Open node settings
  2. Navigate to "Options" section
  3. Enable "Retry On Fail"
  4. Set "Max Tries" (recommended: 3)
  5. Set "Wait Between Tries" in milliseconds (recommended: 5000)

Retry Configuration by Use Case:

External API

calls:

  • Max Tries: 3
  • Wait Between: 5000ms (5 seconds)
  • Use exponential backoff if available

Database queries:

  • Max Tries: 2
  • Wait Between: 2000ms (2 seconds)
  • Fail fast on connection errors

Webhook

deliveries:

  • Max Tries: 5
  • Wait Between: 10000ms (10 seconds)
  • Long delays prevent rate limit violations

Access Retry Information in Downstream Nodes:

The retry system exposes attempt counts:

Current attempt: `{{$node["HTTP Request"].context.attempt}}`
Max attempts: `{{$node["HTTP Request"].context.maxAttempts}}`

Use this to send escalating notifications. First failure? Log it. Third failure? Page someone.

Exception Queue Pattern

Build a dedicated error handling workflow that processes failures from multiple sources. This centralizes your error response logic.

Create Your Exception Queue:

  1. Build a new workflow named "Exception Handler"
  2. Add a Webhook
    node as the trigger
  3. Set authentication (use header auth with a secret token)
  4. Copy the webhook
    URL

Route Errors to the Queue:

In your production workflows, connect error outputs to an HTTP Request node:

Method: POST
URL: [Your Exception Handler webhook URL]
Authentication: Header Auth
Header Name: X-Error-Token
Header Value: [Your secret token]

Body (JSON):
{
  "workflow": "`{{$workflow.name}}`",
  "node": "`{{$node.name}}`",
  "error": "`{{$json.error.message}}`",
  "timestamp": "`{{$now}}`",
  "data": `{{$json}}`
}

Process Errors in the Handler:

Your Exception Handler workflow can now:

  1. Parse incoming error data
  2. Check error severity (HTTP 5xx vs 4xx)
  3. Route to appropriate channels (Slack for urgent, email for info)
  4. Store in database for trend analysis
  5. Trigger automated remediation (restart services, clear caches)

Example Handler Logic:

IF node: Check error type
  Condition: `{{$json.error}}` contains "timeout"
  True branch: Send to #ops-urgent Slack channel
  False branch: Log to Airtable only

IF node: Check retry eligibility
  Condition: `{{$json.retryCount}}` < 3
  True branch: Wait 30 seconds, retry original workflow via API
  False branch: Mark as failed, notify team

Practical Error Handling Patterns

Pattern 1: Graceful Degradation

When a non-critical API

fails, continue with partial data:

HTTP Request (with Continue on Fail enabled)
  Success output: Merge with main data
  Error output: Set default values, continue workflow

Pattern 2: Circuit Breaker

Stop calling a failing service after repeated failures:

Store failure count in workflow static data
IF failures > 5 in last hour:
  Skip API call
  Use cached data
  Send alert to ops team

Pattern 3: Dead Letter Queue

Failed items go to a holding area for manual review:

Error output: Write to "Failed Items" Google Sheet
Include: Original data, error message, timestamp
Daily summary: Email list of failed items to data team

Testing Your Error Handlers

Don't wait for production failures to validate your error handling.

Force Errors in Development:

  1. HTTP Request node: Use URL https://httpstat.us/500 (returns 500 error)
  2. Code node: Add throw new Error('Test error');
  3. Function node: Reference undefined variables

Verify Error Outputs:

  1. Execute workflow manually
  2. Check error output contains expected data
  3. Confirm notifications sent correctly
  4. Validate error logs written to database

Load Test Error Handling:

Run 10 executions simultaneously with forced errors. Your error handler should process all without dropping messages or creating duplicates.

Monitoring and Alerting

Error handling isn't complete without visibility.

Essential Metrics to Track:

  • Error rate by workflow (errors per 100 executions)
  • Error rate by node type (which integrations fail most)
  • Mean time to recovery (how long errors persist)
  • Retry success rate (do retries actually work)

Set Up Alerts:

  • Error rate exceeds 5% in any workflow: Slack notification
  • Same error occurs 10 times in 1 hour: Page on-call engineer
  • Critical workflow fails: Immediate SMS alert

Build a simple dashboard in Google Sheets or Airtable that pulls from your error log. Review weekly to identify patterns and improve reliability.

Your workflows will fail. The question is whether you'll know about it and have a plan to respond.

Revenue Institute

Reviewed by Revenue Institute

This guide is actively maintained and reviewed by the implementation experts at Revenue Institute. As the creators of The AI Workforce Playbook, we test and deploy these exact frameworks for professional services firms scaling without new headcount.

Revenue Institute

Need help turning this guide into reality? Revenue Institute builds and implements the AI workforce for professional services firms.

RevenueInstitute.com