n8n Error Workflow Setup: Catch and Alert on Workflow Failures

Every production n8n workflow will fail eventually. An API returns 500, a credential expires, a webhook times out. Without an error workflow, these failures happen silently. You discover them days later when a customer asks why their confirmation email never arrived. An error workflow catches the failure, alerts you, and optionally retries or compensates. Every n8n instance running production traffic should have one.

How Error Workflows Work

An error workflow is a regular workflow that starts with the Error Trigger node instead of a webhook or schedule trigger. When any other workflow fails, n8n fires the Error Trigger with a payload describing the error (which workflow, which node, the error message, the execution ID, timestamp). Your error workflow can then alert, log, or retry.

Creating the Error Workflow

Step 1: create a new workflow. Step 2: add an Error Trigger node as the start. Step 3: add whatever alerting you want. Typical pattern is Slack (for dev channel) or email (for critical workflows) plus a row appended to a tracking sheet. Step 4: save and activate the workflow.

The error workflow does nothing until you link it to other workflows. Each workflow that needs error handling must have its error workflow field set in the workflow settings.

Linking Error Workflow to Production Workflows

Open each production workflow, go to Settings, and under "Error Workflow" select your error workflow. Save. Now when this workflow fails, n8n fires the error workflow with the failure payload.

In newer n8n versions you can set a default error workflow at the instance level so new workflows inherit it automatically. This prevents the common oversight of forgetting to attach error handling on a new production workflow.

What the Error Payload Contains

The Error Trigger receives an execution object with: workflow name and ID, the specific node that failed, the error message, the stack trace (if available), execution ID (so you can link back to the run), and timestamp. Use these fields in your alert so you can diagnose fast.

Building a Useful Slack Alert

A good alert has: workflow name (so you know what broke), node name (where it broke), error message (why it broke), link to the execution in n8n UI (for detailed debugging), and timestamp. Use Slack's block kit or attachment format to make it visually scannable. A noisy alert channel that floods the team gets muted within a week; a well-formatted channel that only surfaces real issues gets checked.

Separate alerts into channels by severity. Critical failures (payment processing, customer-facing) go to an on-call channel with immediate notification. Non-critical (analytics, reporting) go to a lower-priority channel checked during business hours.

Retry Logic

Some failures are transient (rate limits, network blips, 5xx errors). Retrying often succeeds. In the failing workflow, enable "Retry On Fail" on the relevant nodes with 2 to 3 retries and exponential backoff. This handles transient errors without involving the error workflow at all.

For failures that survive retries, the error workflow fires. At that point, you may want to trigger a delayed re-run (e.g., re-queue the job 1 hour later) rather than requiring manual intervention. Store failed job payloads in a database and have a scheduled workflow retry them periodically.

Conditional Alerting

Not every error needs to wake you up at 3am. Use an IF node in the error workflow to filter: only alert if the workflow name matches a critical list, only alert if the same error has happened more than N times in an hour (to avoid flooding), only alert during business hours for non-urgent workflows.

Logging Errors to a Database

In addition to alerts, append every error to a persistent log. Airtable, Postgres, or a dedicated logging service. Columns: timestamp, workflow name, node name, error message, raw payload (for reproduction), resolution status. This log is gold when you need to prove a pattern, justify infrastructure investment, or explain to a customer what happened.

Testing the Error Workflow

Test it manually. Add a Code node to a test workflow that throws: "throw new Error('test failure');". Execute the workflow. Verify the error workflow fires and the alert arrives. Do this whenever you change the error workflow.

Common Pitfalls

The error workflow itself fails. If your alert Slack webhook is misconfigured, errors silently disappear. Test the alert path weekly. Error workflow not linked to production workflows. Easy to forget when creating new workflows; use a default error workflow or a checklist. Alerts too noisy. If the alert channel gets flooded with known-benign errors, the team mutes it and real issues get missed. Filter aggressively. No record of failures. An alert you dismiss is gone. Always append to a log so you can go back and look at patterns.

The error workflow is one of the highest-ROI pieces of infrastructure you will set up in n8n. Spend an afternoon getting it right and it saves you hours per month of silent-failure chasing.