Your n8n workflows can fail at 2 a.m. and tell you nothing. You add an Error Workflow, wait for the next failure… and the alert never fires.
This is one of the most common “it should work” traps in n8n. Search results for n8n error workflow not triggering are mostly docs and forum threads, so here is a single checklist you can walk through in about ten minutes.
Scope of this article: documented against self-hosted n8n 2.44.6. Not tested on n8n Cloud. Notification examples use Slack or SMTP only.
What an Error Workflow actually is
An Error Workflow is a normal workflow whose first node is an Error Trigger. You point other workflows at it under Settings → Error workflow. When a monitored workflow fails in the way n8n considers “unhandled,” the Error Trigger runs and you can send Slack or email.
It is not a global catch-all for every red node you see while clicking around in the editor.
Checklist: why it is “not triggering”
Work top to bottom. Most “not triggering” reports are one of these.
1. You tested with a manual run in the editor
Error Workflows are meant for automatic / production executions (schedules, webhooks, app triggers on a published workflow). A manual Execute workflow click in the canvas often will not invoke the Error Workflow.
Fix: publish (activate) a throwaway workflow, give it a real trigger (or Schedule), force a failure there, then check Executions on the Error Workflow—not only the editor toast.
2. The Error Workflow is not selected on the failing workflow
Open the workflow that failed → Settings (or Options → Settings) → Error workflow → pick your handler → save / publish again.
In newer n8n versions, both the monitored workflow and the error handler may need to be published. If you only saved a draft, production failures will not see the setting.
3. The failure was “handled,” so n8n does not escalate
If a node uses Continue On Fail, or you wired the node’s error output and handled it yourself, the execution can finish without counting as an unhandled workflow failure. The Error Trigger stays quiet.
Fix: for the path you want alerts on, turn off Continue On Fail and do not swallow the error on a side branch—or accept that handled errors will not page you.
4. The Error Trigger is not the first node (or the handler itself errors)
The handler must start with Error Trigger. Keep the alert path short: Error Trigger → Set/Compose → Slack or Send Email (SMTP). Avoid putting fragile HTTP/LLM steps on the critical path unless they are set to continue on error and are clearly optional.
5. You are looking at the wrong place for proof
Production Error Workflow runs show up under Executions for that workflow. They may not paint a big banner on the workflow that failed. Confirm:
- the failing workflow has a failed production execution;
- the Error Workflow has a matching new execution at about the same time;
- Slack/SMTP credentials on the handler are valid (a bad credential makes it look like “nothing happened”).
6. Instance / URL gotchas (self-hosted)
If your alert includes an execution link, the instance public URL must be configured correctly, or the link is useless even when the trigger did fire. That is a separate issue from “not triggering,” but it is often reported together.
Minimal documented pattern (Slack or SMTP)
- New workflow → Error Trigger.
- Edit Fields (Set) for subject/channel/recipient prefixes.
- Slack Send message or Send Email (SMTP) with workflow name, failed node, error message, and execution URL from the Error Trigger payload.
- Publish the handler.
- On every workflow you care about: Settings → Error workflow → select it → publish.
To force a failure on purpose: add a Stop And Error node on a published schedule/webhook workflow, run it once in production mode, then verify the handler execution.
Optional AI “explain this error” steps are fine only if they cannot block the alert (continue on error, off by default).
Documented on self-hosted n8n 2.44.6; not tested on n8n Cloud. Import-checked with sample data; real Gmail/Slack/SMTP/LLM behaviour in your environment still needs your own verification.
This post was generated with an AI agent and reviewed by me before publishing.
Top comments (2)
The manual-run point is the one that gets almost everyone. One addition that saved me: errors that never "fail" the workflow. An HTTP Request node with "Continue On Fail" on, or an AI Agent that returns an empty answer, ends in a green execution, so the Error Trigger never fires. I add an IF node after the risky step that checks the output is non-empty and uses a Stop And Error node when it isn't, which turns the silent case into a real failure the Error Workflow can catch. Have you found a cleaner way to handle those?
Point 3 is the one that catches people most. If a node uses Continue On Fail, the run counts as finished, so no alert fires. Do you add an explicit Stop and Error node on the branches you want to page you?