The n8n Error Trigger is great - for errors

The standard advice for n8n reliability is: add an Error Trigger workflow, wire it to Slack, done. It’s good advice - we give every account a preconfigured Error Reporter template built on exactly that node, and you should use it.

But “done” is doing a lot of work in that sentence. The Error Trigger fires when a workflow execution errors. Here are five ways automations die that never produce an error - which means the Error Trigger, by design, sees none of them.

1. Silence

A webhook provider rotates a key and stops calling your webhook. A schedule trigger gets disabled during an edit. An upstream app disconnects. In every case the workflow doesn’t fail - it stops being triggered. Zero executions means zero errors means zero alerts. This is the most expensive failure mode in automation, and it’s structurally invisible to error-based monitoring. We wrote up the exact algorithm we use to catch it.

2. A dead instance

When the whole n8n instance is down - container crashed, VPS billing lapsed, disk full - your error workflow is down with it. A monitor that lives inside the thing it monitors disappears at exactly the moment you need it. Instance health has to be watched from outside.

3. The deactivated workflow

Someone toggles a workflow off to debug something and forgets to turn it back on. n8n is doing exactly what it was told; there is nothing to error. Unless something is tracking which workflows should be active and running on cadence, that switch stays off until a client notices the output stopped.

4. A vulnerable version

n8n ships security fixes; instances lag behind them. Your Error Trigger has no opinion about whether the version you’re running falls inside a published advisory range. We sync advisories from GitHub and match them against the versions your instances report, linking the source advisory in every alert - and when we can’t observe a version, we say unknown instead of guessing.

5. Fifteen clients

The Error Trigger is per-instance plumbing. Run automations for one company and that’s fine. Run them for fifteen clients and you have fifteen error workflows to keep configured, fifteen Slack channels to watch, and no single view of which client is healthy - let alone a health report you can attach to a retainer invoice.

Keep the Error Trigger. Cover the rest.

Error alerts are table stakes. Silence is what kills you. The setup that actually works is both layers: the Error Reporter inside n8n for instant failure detail, and an outside observer for silence, instance health, versions, and the fleet view - monitored in about five minutes, no card.