n8n Error Handling: Error Workflows, Retries & Alerts

n8n error handling is built from three native tools: the Error Trigger (which runs a dedicated error workflow whenever a workflow throws), per-node retry settings with backoff, and the per-node "Continue On Fail" toggle that lets a run survive a failing node. Together they cover thrown errors well — you can alert on failures, retry transient ones, and keep a batch job going when one item breaks. What they don't cover is the run that finishes green while doing the wrong thing, and that gap is where most real incidents live. This guide is the how-to: set the native tools up correctly first, then know exactly where they stop.

What n8n gives you natively

Three settings do the work. The Error Trigger is a node that starts a special workflow which n8n runs automatically whenever a monitored workflow throws — you assign it under Settings → Error Workflow. Per-node retries live on each node's Settings tab ("Retry On Fail," plus max tries and wait-between-tries), and they re-run just that node on a transient failure. "Continue On Fail," also per node, tells n8n to pass the error down the output instead of stopping the whole run, so a loop over 500 items doesn't die on item 3.

Used together these are a solid baseline: retries absorb the flaky-network failures, Continue On Fail keeps batch jobs alive, and the Error Workflow makes sure a genuine throw reaches a human. The catch is that all three only engage on an actual thrown error. A node that returns a 200 with an error body in it, or a mapping that silently writes an empty field, sails straight through — no retry, no Error Trigger, nothing.

Set up a global error workflow (do this first)

This is the free baseline, so start here. Create a new workflow whose first node is an Error Trigger. The trigger hands you the failed workflow's name, the execution ID, and the error message and stack. Add a Slack (or email) node that formats those into a readable alert — include a link to the execution so you can jump straight to the failed run — then save. Finally, go to Settings → Error Workflow and select this workflow as the global default, so every workflow uses it unless one overrides it with its own.

One workflow now covers your whole instance. When anything throws, you get a ping in a channel you actually watch, with enough context to open the exact execution. Keep this even after you add heavier monitoring — it's the fastest path from "a workflow threw" to "a human knows," and it costs nothing to run. For the failure patterns it can't see, n8n error tracking picks up where it leaves off.

Retry and backoff best practices

Retries are for transient failures — a rate limit, a brief network blip, a 502 from an upstream API. They are not for logic errors: retrying a request that's missing a required field just fails four times instead of once. Turn "Retry On Fail" on only for nodes that call external services, and leave it off for pure data-transform nodes where a failure means your data is wrong.

Space the attempts out. A fixed 1-second wait hammers an API that's already rate-limiting you; prefer a longer gap (a few seconds) and a low max-tries (3 is usually plenty). If you need true exponential backoff, n8n's fixed wait won't give it to you — put the failing call inside a sub-workflow or wrap it with a Wait node whose delay you compute from the attempt number. Two rules keep retries honest: make the operation idempotent (retrying a non-idempotent write can create duplicate records), and count your retries as cost, because every failed LLM or paid-API attempt still bills you — the retry tax covered in n8n cost tracking.

Where native error handling stops

Every native tool keys off a thrown error. That leaves whole classes of failure invisible, and it gives you no view across runs — the Error Trigger fires per execution, so it can't tell you a node's error rate is climbing or that failures cluster on one credential. Here's the map of what the Error Trigger does and doesn't catch, and what to do about each:

Beyond native: catch what doesn't throw

Native error handling answers "did this run throw?" The harder questions — what's failing across everything, is it getting worse, and which runs finished green but wrong — need monitoring that treats failures as a pattern rather than an event. That means per-node error rates, clustering by error type and credential, error-rate trend against each workflow's own baseline, and validation of output content so the silent failures surface. Those green-but-wrong runs are usually the ones that cost you customers; the full playbook is in debugging silent failures in n8n.

You can build this from the n8n API and a time-series store, or connect a tool read-only. Obsivara syncs your executions with no logging nodes and no proxy in your request path, attributes each error to its workflow and node, clusters them, and alerts on error-rate drift before it becomes an outage — sitting alongside the native Error Trigger, not replacing it. Start with a free 48-hour audit to see what's failing quietly right now, or read the complete guide to monitoring n8n workflows for the full picture including cost and health.