n8n Error Tracking: Catch Failed Workflows Before Users Do
n8n's Error Trigger catches one failure at a time. Here's how to do real n8n error tracking — alerting, error clustering across every workflow, and the silent failures that never throw at all.
n8n error tracking means capturing, alerting on, and analysing workflow failures across your whole estate — not squinting at one red execution at a time. n8n gives you two native tools: the execution list and the Error Trigger. They're a fine baseline for catching a workflow that threw an error, but they fire one execution at a time, don't cluster or trend failures, and miss the worst kind entirely: the run that finishes green while quietly doing the wrong thing. This guide covers both — the native setup, and what you need on top of it.
What n8n gives you natively
n8n has a built-in error path. Under Settings → Error Workflow you assign a dedicated workflow that starts with an Error Trigger node and runs whenever a monitored workflow throws. Wire that to Slack or email and you'll at least hear about thrown errors instead of discovering them from an angry user. Set it once, globally, and it covers everything.
The limits show up fast at scale. The Error Trigger fires only on actual thrown errors — a node that returns a 200 with an error body, or a loop where 30 of 500 items fail under "Continue On Fail," never triggers it. It's also per-execution: you get a ping per failure, but no view of which node fails most, whether your error rate is climbing week over week, or which failures cluster on one credential or one time of day.
Set up the native error workflow (do this first)
It's the free baseline, so start here. Create a new workflow whose first node is an Error Trigger. Add a node that formats the error (it receives the failed workflow's name, execution ID, and the error message) and posts to your alert channel — Slack, email, or an incident tool. Then set it as the global Error Workflow in Settings so every workflow uses it unless overridden. Now thrown errors reach a channel you actually watch.
What native error tracking misses
The Error Trigger answers "did this run throw?" Real error tracking answers "what's failing across everything, how often, and is it getting worse?" Those are different questions, and the gap is where incidents hide:
| Symptom | What n8n shows | What you actually need |
|---|---|---|
| Node threw an error | Error Trigger fires (per run) | Same, plus which node/credential clusters the failures |
| 30 of 500 loop items failed | "Success" (Continue On Fail) | Per-item failure rate + which items |
| Node returns 200 with an error body | Nothing — no throw | Output validation across runs (silent failure) |
| Error rate creeping up over a week | Each run looks isolated | Error-rate trend vs the workflow's baseline |
| Same failure across many workflows | One ping per execution | Clustering by error type / node / credential |
Error tracking across every workflow
The durable fix is monitoring that treats failures as a pattern, not an event: per-node error rates, clustering by error type and credential, error-rate trend against each workflow's own baseline, and alerts when any of them moves — plus detection of the silent failures that never throw. That last part matters because the failures that cost you customers are usually the green-but-wrong ones, covered in debugging silent failures in n8n.
You can build this with the n8n API and a time-series store, or connect a tool that does it read-only. Obsivara syncs your n8n executions with no logging nodes and no proxy, attributes each error to its workflow and node, clusters them, and alerts on error-rate drift before it becomes an outage. It fits alongside the native Error Trigger — keep that for instant thrown-error pings, add cross-run tracking for the patterns. The complete guide to monitoring n8n workflows shows the full picture, cost and health included.
Frequently asked questions
How do I get alerted when an n8n workflow fails?
For thrown errors, set a global Error Workflow (Settings → Error Workflow) that starts with an Error Trigger node and posts to Slack or email — it fires on any monitored workflow that throws. For failures that don't throw (silent failures, item-level failures in loops) or for error-rate trends across many workflows, you need cross-run monitoring like Obsivara that alerts on clustering and drift, not just individual throws.
What is an n8n Error Workflow?
A dedicated workflow, set globally or per-workflow under Settings → Error Workflow, that begins with an Error Trigger node and runs whenever a monitored workflow throws an error. It receives the failed workflow's name, execution ID, and error, so you can route failures to an alert channel. It only fires on thrown errors, not on runs that succeed with bad data.
How do I track errors across all my n8n workflows?
The native Error Trigger is per-execution, so for an estate-wide view you either query the n8n API and aggregate errors yourself, or connect a read-only observability tool. Obsivara attributes every error to its workflow and node, clusters them by type and credential, trends the error rate against each workflow's baseline, and alerts when it climbs.
Why does my n8n workflow fail silently?
Because n8n's status only means every node finished without throwing — not that the data was right. A node can return a 200 with an error body, reference a missing field and write an empty value, or fail on some items in a loop while "Continue On Fail" keeps the run green. These never trigger the Error Trigger, so you need output/item-count validation across runs to catch them.
See your AI operations clearly.
Connect your stack in minutes — Obsivara discovers every workflow, scores its health, and attributes every dollar.