n8n Error Trigger: Workflow-Level Error Catching and When It Actually Fires

When an n8n workflow fails in production, you have two options: find out from an angry stakeholder, or find out from your error handler. The Error Trigger node is how you build the second option.

But the Error Trigger has some unintuitive behavior that bites most n8n users at some point. Here is how it actually works.

What the Error Trigger Node Does

The Error Trigger is a special trigger node that starts a workflow when another workflow encounters an uncaught error. You create a dedicated “error handler” workflow with an Error Trigger at the start, then attach your other workflows to it.

When an attached workflow fails, n8n automatically executes the error handler with a payload containing:

• The name and ID of the failed workflow
• The node that caused the failure
• The error message and stack trace
• The execution ID for cross-referencing in the execution log
• Timestamp of the failure

This gives you everything you need to send a Slack notification, write to a dead-letter queue, trigger a retry, or file a support ticket — automatically.

Setting Up the Error Trigger

Step 1: Create an error handler workflow

Create a new workflow. Add an Error Trigger node as the first node. Build your notification logic — typically a Slack or email notification with the error details from {{ $json.workflow.name }} and {{ $json.error.message }}.

Step 2: Attach it to your other workflows

In each workflow you want to monitor, go to workflow settings (the gear icon in the editor). Under “Error Workflow,” select your error handler. Save.

That’s it. The connection is per-workflow — you can have one error handler for all workflows, or different handlers for different severity levels.

When the Error Trigger Fires

The Error Trigger fires when a workflow execution ends in an error state. Specifically:

• A node throws an exception that is not caught by a downstream “Continue On Fail” setting
• A node times out
• The execution is explicitly stopped with an error

The error workflow runs with the same n8n credentials and permissions as any other workflow.

When the Error Trigger Does NOT Fire

This is where most confusion happens.

Manually stopped executions: If you manually stop a running execution from the n8n UI, the Error Trigger does not fire. Stopped is not the same as failed.

Test/manual executions: Error Triggers only fire for production executions (triggered by webhooks, schedules, or other workflows). If you test a workflow by clicking “Execute Workflow” in the editor, failures do not trigger the error handler.

Continue On Fail nodes: If a node has “Continue On Fail” enabled, errors in that node do not propagate — the workflow continues with an error output instead of failing. These are not caught by the Error Trigger.

Error handler failures: If the error handler workflow itself fails, there is no secondary error handler — you get a silent failure. Always make the error handler as simple as possible.

Workflow-level timeout: If your entire workflow hits the global execution timeout (configurable in n8n settings), it may or may not trigger the error workflow depending on how the timeout is implemented. Test this explicitly in your environment.

The Error Trigger Payload

When the Error Trigger fires, the incoming data looks like this:

{
  "execution": {
    "id": "1234",
    "url": "https://your-n8n.com/workflow/5678/executions/1234",
    "retryOf": null,
    "error": {
      "message": "Request failed with status code 429",
      "stack": "Error: Request failed with status code 429..."
    },
    "lastNodeExecuted": "HTTP Request",
    "mode": "trigger"
  },
  "workflow": {
    "id": "5678",
    "name": "Daily Data Sync"
  }
}

Access these in your error handler nodes using expressions:

• {{ $json.workflow.name }} — failed workflow name
• {{ $json.execution.error.message }} — error message
• {{ $json.execution.id }} — execution ID for log reference
• {{ $json.execution.lastNodeExecuted }} — which node failed

Production Patterns

Basic Slack Alert

The simplest useful error handler sends a Slack message:

⚠️ Workflow failed: {{ $json.workflow.name }}
Error: {{ $json.execution.error.message }}
Node: {{ $json.execution.lastNodeExecuted }}
Execution: {{ $json.execution.url }}

Dead-Letter Queue

For critical data pipelines, instead of just alerting, write failed executions to a PostgreSQL table or S3 bucket for later replay:

INSERT INTO failed_executions (workflow_name, workflow_id, execution_id, error_message, failed_at)
VALUES ($1, $2, $3, $4, NOW())

Conditional Severity Routing

If you have multiple workflows with different criticality, use a Switch node in your error handler to route to different notification channels:

• Revenue pipeline fails → PagerDuty + Slack
• SEO content generator fails → Slack only
• Reporting workflow fails → Email digest

Auto-Retry Logic

For transient failures (rate limits, temporary API downtime), you can trigger a retry from the error handler using the n8n API:

POST /api/v1/executions/{id}/retry

Combine with a counter stored in Redis or a database to avoid infinite retry loops.

Common Mistakes

Not attaching the error handler to newly created workflows. The Error Workflow setting is per-workflow and must be set manually. New workflows don’t inherit it.

Putting complex logic in the error handler. The more complex your error handler, the more likely it is to fail itself. Keep it to: capture context → notify → optionally log. Anything more belongs in a separate workflow triggered by the notification.

Missing the test/production split. If you notice your error handler never fires during development, this is why. Test executions are intentionally excluded. Use the execution log to see test failures.

Relying on error triggers for data validation. If a workflow produces wrong data without throwing an error — for example, an API returns 200 with an empty array instead of failing — the Error Trigger will not catch it. Add explicit validation nodes for data quality checks.

Conclusion

The n8n Error Trigger is essential for production reliability, but it has a narrower blast radius than most users expect. It catches uncaught node errors in production executions — nothing more. Understanding exactly when it fires (and when it does not) lets you fill the gaps with Continue On Fail logic, explicit validation nodes, and well-structured error handler workflows.

For most production n8n setups, a single shared error handler workflow sending Slack notifications covers 80% of what you need. Start there, then layer in dead-letter queues and auto-retry as your data dependencies grow.