Silent workflow failures are expensive. A Stripe webhook stops processing, a CRM sync drops records, an API call times out — and nothing alerts you. The first sign of trouble is a customer complaint or a report with gaps.

By default, n8n logs failed executions to execution history and stops. Nothing else happens. For workflows running in the background dozens of times a day, that's not good enough.

n8n includes a built-in mechanism to catch every unhandled error across your entire account: the Error Workflow. When configured, it intercepts failures from any workflow and routes them to a central handler you control. This guide walks through building that handler — with classification, retry logic, Slack alerts, and an error log.

How n8n's Error Workflow Feature Works

In your n8n instance, navigate to Settings → Workflow Settings (or the global settings depending on your version). There's an "Error Workflow" field where you can point to any workflow in your account. Once set, every unhandled error from every workflow triggers that designated workflow automatically.

Inside the error handler, you get a full data object describing the failure: the workflow name, the node that failed, the error message, the execution ID, and a direct URL back to the failed execution. You work with this data to decide what to do next.

The Workflow Blueprint

Step 1: Create the Error Handler Workflow

Create a new n8n workflow and name it "Error Handler" or similar. This is a standalone workflow — it never gets triggered by a user or a schedule. Its only trigger is other workflows failing.

Go to your account settings and set this as your Error Workflow.

Step 2: Add the Error Trigger Node

Add an Error Trigger node as the workflow's starting point. This node fires automatically when any error is routed to this handler. No configuration is required on the node itself.

The Error Trigger makes the following fields available downstream:

• workflow.name — which workflow failed
• error.message — the raw error text
• error.node.name — which node inside the workflow failed
• execution.id — the ID of the failed execution
• execution.url — a direct link to view the failed execution in your n8n instance

Step 3: Classify the Error With an IF Node

Not all errors are worth retrying. A 401 Unauthorized error means a credential is wrong — retrying won't help. A 429 rate limit or a network timeout is transient and worth retrying.

Add an IF node after the Error Trigger. Inspect the error.message field using text contains conditions:

• Transient (retry): messages containing "429", "timeout", "ETIMEDOUT", "ECONNRESET", "rate limit", "too many requests"
• Permanent (skip retry): messages containing "401", "403", "unauthorized", "forbidden", "invalid credentials"

Route transient errors to your retry path. Route everything else directly to the alert path.

Step 4: Build Retry Logic With Wait and HTTP Request Nodes

On the transient error path, add a Wait node configured for 2 minutes. This pauses execution before attempting a retry, giving overloaded APIs time to recover.

After the Wait node, add an HTTP Request node. Configure it as a POST request to your n8n instance's REST API retry endpoint — the path is /api/v1/executions/{execution_id}/retry where the execution ID comes from the execution.id field in the Error Trigger data. Include your n8n API key in the Authorization header as a Bearer token. This call re-runs the original failed execution with the same input data it originally received — no manual rebuilding of the trigger payload needed.

Add a second IF node after the HTTP Request to check the response. If the retry execution succeeded, end the branch. If it failed again, increment a retry counter using a Set node and check whether retries have exceeded 3. If they have, route to the alert path. If not, loop back through the Wait node — with the wait time increased by setting the Wait node duration from a field rather than a fixed value.

Step 5: Send a Slack Alert

When retries are exhausted — or for non-retryable errors — add a Slack node. Post to a channel your team actively monitors, such as #alerts or #ops.

Structure the Slack message to include the workflow name, the node that failed, the error message, how many retries were attempted, and a clickable link to the execution using the execution.url field from the Error Trigger data. With this information, the person responding has everything they need to diagnose the issue without opening n8n and searching through execution history manually.

For critical workflows — payment processing, compliance syncs, customer-facing automations — also add a Gmail node to send an email to the responsible engineer. Slack can be muted or missed; email is a harder-to-ignore escalation channel.

Step 6: Log Every Error to Google Sheets

Add a Google Sheets node as the final step on all error paths. Append one row per error with:

• Timestamp (use the current date/time)
• Workflow name
• Failed node
• Error message
• Retry count
• Whether it auto-resolved or required manual intervention
• Execution URL

This log pays off within a few weeks. When you see the same workflow failing every Monday morning, that's a data volume problem. When auth errors spike every 30 days, that's a token expiry pattern. Recurring failures show up as trends in the sheet rather than as noise in Slack.

Example n8n Workflow: Complete Error-Handling Flow

1. Error Trigger node — receives failure data from any workflow in the account
2. IF node (error type) — routes transient errors to retry, permanent errors to alert
3. Wait node (2 min) — pauses before the first retry attempt
4. HTTP Request node — calls the n8n API to retry the failed execution by ID
5. IF node (retry limit) — checks whether retries have exceeded the threshold
6. Set node (increment counter) — bumps the retry counter and loops back if needed
7. Slack node — sends alert with workflow name, error, node, retry count, and execution link
8. Gmail node — sends email escalation for critical workflow failures
9. Google Sheets node — appends a row to the error tracking log

This flow handles the full lifecycle: detect, classify, retry automatically, escalate when retries fail, and log everything.

What You Get in Practice

Once the Error Handler is live, you stop discovering workflow failures from user reports. Transient API failures resolve themselves on the first or second retry — most of the time without any Slack alert. Genuine failures surface immediately with the context needed to fix them.

More importantly, every workflow in your account inherits this behavior without any changes to the individual workflows themselves. Your existing automations — your CRM sync, your invoicing pipeline, your data ingestion jobs — all get retry and alerting coverage from one central place.

Browse n8nresources.dev/templates for pre-built error handling and monitoring workflows that you can import directly. For building more reliable automation patterns without code, see n8n no-code automation workflows.