n8n error workflows with the Error Trigger node

An n8n error workflow is a separate workflow that runs whenever another workflow's execution fails. It starts with the Error Trigger node, receives details about the failure, and does whatever you want with them: post to Slack, send an email, open a ticket. One error workflow can cover every workflow on the instance. This page is the reference: setup, the exact payload, an alert template, and how error workflows fit with node-level retries and error outputs.

For the migration angle (Pipedream's error emails, auto-retry and $errors source), see Pipedream error handling to n8n.

Set it up

1. Create a workflow with Error Trigger as the first node. Name it, for example, Error Handler, and save.
2. Add the alert nodes after it.
3. In each workflow you want covered, open Workflow Settings and pick Error Handler under Error workflow (to notify when this one errors). Save.

Three rules from the Error Trigger docs:

• A workflow that uses the Error Trigger doesn't have to be published.
• A workflow containing the Error Trigger uses itself as its error workflow by default.
• You can't test it with manual runs: it fires only when an automatic execution fails.

To test, publish a small workflow with a Schedule Trigger every minute and a Stop and Error node, set the error workflow, and wait for the first run. Unpublish it afterwards.

The payload

When a node fails after the trigger ran, the Error Trigger outputs:

{
  "execution": {
    "id": "231",
    "url": "https://n8n.example.com/execution/231",
    "retryOf": "34",
    "error": { "message": "Example Error Message", "stack": "Stacktrace" },
    "lastNodeExecuted": "Node With Error",
    "mode": "manual"
  },
  "workflow": { "id": "1", "name": "Example Workflow" }
}

Field	Present when
execution.id, execution.url	The execution was saved to the database
execution.retryOf	The execution is a retry of a failed one
execution.error.message / .stack	Always (for non-trigger errors)
execution.lastNodeExecuted	Always: the node that failed
workflow.id, workflow.name	Always

If the trigger node of the failing workflow is what broke (for example a webhook or polling trigger couldn't activate), the payload has a trigger object whose error holds name (such as WorkflowActivationError), message, timestamp and node, and less in execution.

Make sure Save failed production executions is on in the covered workflows' settings, or execution.url will be missing and your alert can't link to the run.

An alert that's useful at 3 a.m.

A Slack or email message with this text, built with expressions:

FAILED: {{ $json.workflow.name }}
Node: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}
{{ $json.execution.url }}
{{ $json.execution.retryOf ? 'Retry of ' + $json.execution.retryOf : '' }}

For trigger failures, add an If node on {{ $json.trigger !== undefined }} and send a different message, since execution.url won't exist.

Useful additions:

• Deduplicate. A broken schedule that runs every minute sends 60 alerts per hour. Store the last alert time per workflow in a Data table and skip repeats within an hour. Pipedream did this for you (one email per error per workflow per 24 hours); n8n doesn't.
• Route by workflow. A Switch node on workflow.name or a tag sends finance workflows to the finance channel.
• Keep it simple. If the error workflow calls a flaky API and fails itself, you lose the alert. Slack or email via SMTP are good first channels.

Stop and Error: fail on purpose

Some failures don't throw: an API returns 200 with "success": false, a lookup finds nothing. Add a Stop and Error node on that branch (docs):

Error Type	You provide
Error Message	A string, expressions allowed: Customer {{ $json.id }} not found
Error Object	A JSON object with the properties you want to pass

The execution fails, appears as failed in the Executions list, and the error workflow receives your message.

Error workflow vs node settings

An error workflow tells you that something failed. Node settings decide whether a failure is fatal (node settings):

Setting (node Settings tab)	Effect
Retry On Fail	Reruns the node on failure; set Max Tries and Wait Between Tries (ms)
On Error: Stop Workflow	Default; the execution fails and the error workflow runs
On Error: Continue	Goes on with the last valid data
On Error: Continue (using error output)	Adds an error output; failed items go there with the error info
Always Output Data	Outputs an empty item even when the node returns nothing

A robust pattern for API calls:

1. Retry On Fail on the HTTP Request node, 3 tries, 5000 ms apart, for transient errors.
2. Continue (using error output) for item-level failures: route failed items to a Data table or a "needs review" sheet so one bad record doesn't stop the batch.
3. Error workflow for everything else: the run failed and a person should look.

Be careful with Continue: the workflow succeeds, no alert fires, and the bad data travels on. Use the error output instead, so failures are visible.

Execution retries

Failed executions can be retried from the Executions list. A retry carries retryOf with the original execution ID, so your error workflow can tell first failures from failed retries and, for example, escalate only the latter.

Several error workflows

You can have more than one: a noisy one for internal tools, a paging one for customer-facing workflows. Each workflow picks one in its settings. Sub-workflows called with Execute Sub-workflow have their own setting too; see n8n sub-workflows.

Coming from Pipedream

Pipedream emailed you on unhandled errors (at most once per error, per workflow, per 24 hours), offered auto-retry on the Advanced plan (up to 8 times over 10 hours), and let you build a global handler from the Workspace $error events source (Pipedream errors). None of that is in the export. After migrating, nothing alerts you until you set the error workflow on every imported workflow, so make it the first thing you do after the import, before switching traffic.

Our converter report lists every workflow so you can tick them off as you assign the error workflow. Code steps that catch errors and call $.flow.rerun() have no direct equivalent; the code step checker flags them. The report and 1 workflow are free. Full export: $3 per workflow, $19 minimum — coming soon. Full process: migrate Pipedream to n8n.

Not affiliated with Pipedream or n8n.