By default, a failed n8n workflow fails silently. Nothing pages you, nothing shows up except a red execution in a list you have to remember to check. An error workflow fixes this: it’s a normal n8n workflow that runs automatically whenever another workflow throws, and routes the failure wherever you actually look — Slack, email, a ticket queue.

How the error trigger works

n8n has a dedicated Error Trigger node. Any workflow that starts with this node can be set as the designated error workflow for other workflows, and it fires automatically with details about what failed: which workflow, which node, the error message, and the execution ID.

This is a separate mechanism from a workflow’s own error handling (like a node’s “Continue on Fail” setting or an IF branch checking for a bad response). Error workflows catch what nothing inside the failing workflow caught — the actual, unhandled crash.

1. Build the error workflow

Create a new workflow. Add an Error Trigger node as the starting point — nothing else triggers this workflow; it only runs when something else fails and routes here.

The trigger’s output gives you a JSON payload with fields like:

{
  "execution": { "id": "1234", "url": "https://n8n.example.com/execution/1234" },
  "workflow": { "id": "5", "name": "Sync Orders to CRM" },
  "trigger": { "mode": "webhook" }
}

Wire that into whatever should notify you. A Slack node is the common choice:

Error Trigger → Slack (Post Message)

Format the message with the fields that actually help you triage without opening n8n first — workflow name and error message, at minimum:

🔴 Workflow failed: {{$json.workflow.name}}
Execution: {{$json.execution.url}}

Including the execution URL directly in the alert saves you from hunting through the executions list for the one that failed — click straight to it.

2. Attach it to your other workflows

The error workflow does nothing until you tell other workflows to use it. Open each workflow you want covered, go to Settings (top right, three-dot menu) → Error Workflow, and select the one you just built.

This is per-workflow, not global. There’s no “apply to all” toggle in the UI, so on an instance with a lot of existing workflows, you’re going through them one at a time. It’s worth it for anything customer-facing or anything moving money — skip it for genuinely low-stakes internal automations if going through dozens of workflows manually isn’t worth your time.

3. Don’t let the error workflow itself become a single point of silent failure

If your error workflow’s own Slack credential expires, or the webhook it posts to starts returning errors, you now have zero visibility into anything — the failure that was supposed to alert you silently fails to alert you. Two ways to guard against this:

• Test it deliberately. Force a failure in a throwaway workflow (a node pointed at a bad URL is enough) and confirm the alert actually arrives.
• Use a notification channel you monitor independently of n8n uptime — Slack or email, not a webhook back into another n8n workflow on the same instance, which fails for the same underlying reasons (instance down, database issue) that caused the original problem.

What this doesn’t replace

An error workflow tells you something broke after the fact. It’s not a substitute for handling expected failure cases inside the workflow itself — a flaky third-party API that fails 2% of the time should have retry logic or a Continue on Fail branch, not just an alert every time it hiccups. Save the error workflow for genuinely unexpected failures: a credential that expired, a node misconfigured after an edit, an API that changed its response shape without warning. If you’re getting paged constantly for the same known-flaky call, that’s a sign to fix the workflow, not tune the alert.