You set an error workflow. You run the failing workflow to test it. Nothing happens.
The error workflow is almost certainly fine. n8n has four documented behaviours here, and the first one explains most of these reports on its own.
Why Is My n8n Error Workflow Not Triggering?
Because you are testing it manually. n8n’s docs say it in bold: “You can’t test error workflows when running workflows manually. The Error Trigger only runs when an automatic workflow errors.” Clicking Test Workflow and watching a node fail will never fire your error handler.
That is not a bug, and it is not something you configure around. Error workflows exist for unattended failures. When you are sitting in the editor watching the execution fail, n8n assumes you can see the error yourself.
To test it, trigger the workflow the way it actually runs - hit the production webhook URL, or wait for the schedule - and let it fail there.
How Do I Force a Failure to Test With?
Add a Stop And Error node. The docs describe it as letting you “force executions to fail under your chosen circumstances, and trigger the error workflow.” Put one on a branch, trigger the workflow automatically, and you have a repeatable test.
The full test loop that actually works:
- Build the error workflow with an Error Trigger as the first node.
- On the failing workflow: Options > Settings > Error workflow, select it.
- Drop a Stop And Error node into the failing workflow.
- Trigger it automatically - production webhook URL, or the schedule.
- Check the executions list of the error workflow, not the failing one.
Step 5 catches people out too. A firing error workflow shows up in its own execution history, not in the failing workflow’s.
Cause 2: The Error Workflow Does Not Start With an Error Trigger
n8n’s docs are unambiguous: “The error workflow must start with the Error Trigger.” A workflow starting with a Webhook, a Schedule Trigger or a Manual Trigger will never be invoked as an error handler, no matter what the setting says.
Two useful details that come with that node:
- It does not need to be published. From the docs: “If a workflow uses the Error Trigger node, you don’t have to publish the workflow.” So an unpublished error workflow is not your problem.
- Self-handling is the default. “If a workflow contains the Error Trigger node, by default, the workflow uses itself as the error workflow.” If you added an Error Trigger to the failing workflow while debugging, that is where your errors have been going.
Cause 3: The Setting Is On the Wrong Workflow
The Error workflow setting is per-workflow, set on the workflow that fails, not on the handler. Setting it once does not apply it to your other workflows - each one needs it, and a duplicated workflow does not reliably carry it.
Worth auditing periodically. The failure mode is silent by definition: a workflow with no error workflow configured fails quietly and you find out from the downstream system that stopped getting data.
Cause 4: It Fired, With a Payload Your Handler Could Not Read
This one is subtle and worth knowing about, because it looks exactly like “not triggering.” When the failure is in the trigger node itself, n8n does fire the error workflow - but sends a different shape of data.
From the docs: “If the error is caused by the trigger node of the main workflow, rather than a later stage, the data sent to the error workflow is different. There’s less information in execution{} and more in trigger{}.”
Specifically, execution.id and execution.url are absent. The docs explain why: execution.id “requires the execution to be saved in the database. Not present if the error is in the trigger node of the main workflow, as the workflow doesn’t execute.”
So an error workflow that opens with something like {{ $json.execution.id }} throws on precisely the errors you most want to hear about - the ones where the workflow never started. Guard those references:
{{ $json.execution?.id ?? 'trigger-level failure' }}A common shape for a robust handler is to branch on whether execution is populated, and send a different message for a trigger-level failure than for a mid-workflow one. They mean different things operationally: one is “a step broke”, the other is “this workflow is not running at all.”
What an Error Workflow Does Not Cover
A workflow that stops being triggered does not error, so no error workflow fires. Nothing has failed - nothing happened. That is a monitoring problem, not an error-handling one, and it is the failure people actually get burned by.
The classic version: a webhook stops receiving calls because the upstream service rotated a URL, or a schedule stops firing because the instance was down. Your error workflow is silent because there were no executions to fail.
Two things that do catch it:
- A heartbeat workflow. A scheduled workflow that pings a dead-man’s-switch service. If the ping stops, you get alerted about the silence.
- Uptime monitoring on the instance. If n8n is down, nothing at all runs, error workflows included. Uptime Kuma is the usual self-hosted answer and runs on a $3/mo pod. If you have not picked a prober yet, we tested the 7 best uptime monitoring tools on check interval, alerting and real cost.
This is also the honest limit of what a host can do for you. We can keep the pod up and tell you when it is not; we cannot know that your workflow was supposed to receive an order at 9am and did not.
Two Things Hosting Does Not Fix
Worth repeating because it comes up in every automation-reliability conversation.
Credential sprawl. If the same API key lives in three n8n credentials, two environment variables and someone’s laptop, error handling does not help - the workflow will fail for reasons no handler can explain. That is key hygiene inside n8n, not a hosting concern. See the n8n encryption key for the part hosting actually touches.
Human approval steps. If a workflow should pause for a person before it moves money or changes a customer record, you build that into the workflow with a wait and an approval path. An error workflow is what runs after something went wrong, which is the wrong end of that problem.
Quick Checklist
| Check | Fix |
|---|---|
| Testing manually? | Trigger automatically. Manual runs never fire it. |
| Handler starts with Error Trigger? | It must be the first node. |
| Setting on the failing workflow? | Options > Settings > Error workflow, per workflow. |
Handler reads execution.id? | Guard it - absent on trigger-level failures. |
| Checked the handler’s own executions? | It logs there, not in the failing workflow. |
| Errors that produce no execution at all? | Needs monitoring, not error handling. |
FAQ
Does the error workflow need to be active? No. Per the docs, a workflow using the Error Trigger does not have to be published.
Can one error workflow serve every workflow? Yes, and that is the usual pattern. Select the same handler in each workflow’s settings. The payload tells you which workflow failed.
Where do I see whether the error workflow ran? In the error workflow’s own execution list. It is a separate execution from the one that failed.
Why did my error workflow fire twice? Usually because the failing workflow also contains an Error Trigger, so it is handling itself as well as calling your handler.
Do errors in sub-workflows trigger the parent’s error workflow? The sub-workflow’s own error workflow setting applies to it. Configure handlers where the failure happens, not only at the top.
Running n8n on a box you would rather not babysit? Deploy n8n on InstaPods for $7/mo - 2 vCPU, 2 GB RAM, HTTPS and daily backups, so instance-level failures are our problem. Workflow-level failures stay yours, and that is what error workflows are for.