🛡️ Lesson 10 of 12

Error Handling &
Reliability

Build workflows that survive the real world. Learn N8N's Error Trigger node, try/catch patterns, retry configuration, and how to set up instant failure alerts so nothing silently breaks in production.

Error Trigger node Try/Catch in Code node Retry settings Slack/Email alerts Idempotency

1The Error Trigger Node

The Error Trigger node is N8N's dedicated failure catcher. You create a separate "error workflow" and link it to your main workflow. Whenever the main workflow fails for any reason, N8N automatically executes the error workflow with full context about what went wrong.

🔨 Main Workflow

Schedule Trigger (every hour)

HTTP Request (fetch data)

Process & transform

Google Sheets (write)

Fails here → triggers error workflow

🚨 Error Workflow

Error Trigger (activated)

Extract error message + context

Send Slack alert to #ops

Log to Google Sheet

Send email to admin

🔵

How to Link an Error Workflow

In your main workflow settings (gear icon), find Error Workflow and select or create your error workflow. The Error Trigger node in that workflow receives the full error payload including the workflow name, node that failed, error message, and timestamp.

Error Trigger — Full Alert Flow

Workflow Fails

→

Error Trigger
receives context

→

Log to Sheet

Slack Alert

Email Admin

2Try/Catch in the Code Node

When making HTTP requests or calling external APIs inside a Code node, you should always wrap the call in a try/catch block. This lets you handle failures gracefully — returning a structured error object instead of crashing the entire workflow.

JavaScript — Code Node

try {
  // Attempt the API call
  const result = await $helpers.httpRequest({
    method: 'GET',
    url: 'https://api.example.com/data',
    headers: {
      'Authorization': `Bearer ${$credentials.apiKey}`
    }
  });

  // Return success with data
  return [{ json: { success: true, data: result } }];

} catch (error) {
  // Return structured error — workflow continues instead of crashing
  return [{ json: {
    success: false,
    error: error.message,
    statusCode: error.response?.status || 500,
    timestamp: new Date().toISOString()
  }}];
}

💡

Fail Gracefully, Not Loudly

By returning a structured error object instead of throwing, you allow downstream nodes to check the success field and route accordingly. Use an IF node after the Code node to separate successful and failed items.

3Retry Settings — Automatic Recovery

N8N has built-in retry logic at the node level. When a node fails due to a transient error (network timeout, 503, rate limit), N8N can automatically retry it before marking the workflow as failed.

Retry on Fail

✅ Enabled

Toggle in node settings under "On Error". Tells N8N to retry this specific node if it throws an error.

Max Tries

3 attempts

How many times to retry before giving up and marking the node as failed. Default: 3.

Wait Between Tries

1,000 ms

How long to wait before each retry attempt. Increase to 3–5 seconds for rate-limited APIs.

Timeout

300,000 ms

Maximum time a node execution can run before N8N forces a timeout. Adjust for slow external APIs.

⚠️

Retries Do Not Fix Logic Errors

Retry logic only helps with transient failures (network hiccups, temporary API downtime). If your node fails due to a bad URL, wrong credentials, or malformed data, retrying will just fail the same way 3 more times. Fix the root cause first.

4Failure Alerting — Slack + Email

A workflow failing silently in production is worse than no automation at all. Build an error workflow that alerts you the moment something breaks — with enough context to diagnose and fix the issue fast.

Production Alerting Flow — Error Workflow

Workflow
Fails

→

Error Trigger
full context

→

Log to
Google Sheet

💬 Slack
#ops-alerts

📧 Email
to admin

💬

What to Include in Your Slack Alert

Your Slack message should include: workflow name ({{ $workflow.name }}), failed node name, error message, execution ID (for linking to N8N logs), and timestamp. This gives you everything needed to diagnose the issue without logging in to N8N first.

5Production Reliability Patterns

The difference between a toy workflow and a production automation is reliability engineering. Here are the four patterns every production N8N workflow should implement:

🔄

Retry Logic

Enable "Retry on Fail" on all HTTP Request and API nodes. Set 3 retries with 2s delays.

Node Settings

🚨

Error Alerting

Link every production workflow to an error workflow that notifies your team via Slack + email.

Error Workflow

✅

Data Validation

Use IF nodes to check that required fields exist and are non-empty before passing data downstream.

IF Node

🔑

Idempotency

Check if an item was already processed before processing it again. Use unique IDs + a lookup table.

Deduplication

🔑

What Is Idempotency?

An idempotent workflow produces the same result whether run once or ten times. Before processing an item (e.g. sending an invoice), check a Google Sheet or database to see if you already processed it. If yes, skip it. This prevents duplicate emails, duplicate charges, and data corruption when workflows retry after partial failures.

6Reliability Stats

3×

Recommended max retries per node

Wait time between retry attempts

99%

Failures caught by Error Trigger in production

🧠 Knowledge Check — Lesson 10

Q1 — Which N8N node activates when a linked workflow fails?

Failure Node

Error Trigger

Exception Handler

Catch Node

Q2 — How do you enable automatic node retries in N8N?

Add a separate Retry node after every API call

Enable "Retry on Fail" in the individual node's settings

Wrap the node in a Code node with a loop

Set it in the global N8N configuration file

Q3 — What reliability pattern prevents duplicate processing when a workflow retries?

Rate Limiting