Why your n8n Error Workflow is not triggering (and how to fix it)

Lantern Flows — Sun, 01 Nov 2026 04:25:19 +0000

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.

DEV Community: Lantern Flows