n8n error handling: catch failed workflows and get a fix

One workflow catches failures for all of them. Create a new workflow whose first node is the Error Trigger. Then open every other workflow, go to Settings, and set Error Workflow to the one you just built.

That setting is per workflow, not global. This is the single most common reason an error workflow appears to do nothing: it was built correctly and then never attached to anything.

Calling Error Workflow for "abc123".
Workflow "xyz789" is not active and cannot be executed

It also will not fire on a manual run. Error workflows are for production executions, so testing by clicking execute on the canvas proves nothing. Publish both, then let a real trigger fail.

Two other cases will not reach it either. A node with continue-on-fail enabled is treated as a successful flagged output rather than a workflow error, so nothing fires. And a workflow that never started, for example a trigger that could not connect, sends a different payload shape, covered below.

Not because the alerts are wrong. Because there are too many of them. A workflow on a one minute schedule with an expired credential fails sixty times an hour, and sends sixty identical emails. After the second incident you filter the sender, and now you have monitoring you never read while still believing you are covered.

The fix is suppression, and it is a handful of lines. Build a key from the workflow, the failing node and the first stretch of the error message. Store the first time you saw it. If the same key comes back inside your cooldown window, increment a counter and do not send.

const store = $getWorkflowStaticData('global');
store.seen = store.seen || {};

const key = [workflowId, nodeName, message.slice(0, 120)].join('::');
const now = Date.now();
const cooldownMs = 30 * 60000;
const prev = store.seen[key];

let shouldAlert = true;
if (prev && now - prev.first < cooldownMs) {
  prev.count = (prev.count || 1) + 1;   // count it, do not send it
  shouldAlert = false;
} else {
  store.seen[key] = { first: now, count: 1 };
}

// and prune, or the store grows forever
for (const k of Object.keys(store.seen)) {
  if (now - store.seen[k].first > cooldownMs * 20) delete store.seen[k];
}

Two details matter here. Pass the repeat count into the alert, so when you do get an email it says this has now happened nine times rather than pretending it is the first. And note that n8n only persists workflow static data on production executions, so the cooldown will appear to do nothing when you test manually from the canvas. Verify it on a real failure.

Four failure classes cover almost everything, and they want different handling. Lumping them together is why a single alert channel stops being useful.

Expired and revoked credentials

The problem. The most common real failure and the most expensive, because it is silent and total. An OAuth token is revoked, and every run after that fails identically until someone notices. This is where the week-long outages come from.

What to do. Treat it as the highest severity even though nothing crashed. It will not fix itself, it affects every run, and the fix takes two minutes once you know. This is the case the whole workflow exists for.

Rate limits and upstream wobbles

The problem. A 429 or a 5xx that would have worked if it ran again a minute later. Alert on these the same way and the noise trains you to ignore the credential alert above.

What to do. Classify them as transient and route them somewhere quiet, or drop them entirely. Better still, set retry on the node itself so they never reach the error workflow. There is nothing to do with the alert when it arrives.

Schema and shape changes

The problem. An API adds a field, renames one, or starts returning null where it used to return an array. Nothing errors loudly. A downstream node reads undefined and the workflow either fails oddly or, worse, succeeds with wrong data.

What to do. These produce the least readable errors, so this is where a plain-English diagnosis earns its keep. It is also the class most worth logging over time, because the same integration breaking twice in a month is telling you something.

Your own expression and logic errors

The problem. A renamed node breaks a $node['Old Name'] reference somewhere else. Cannot read property of undefined. Almost always introduced by an edit, and almost always found by a customer rather than by you.

What to do. Easy to fix, awkward to find out about late. All you want here is speed, so the alert should name the node and link straight to the failed run.

Who feels this most

Agencies running client automations. The outage is bad, being told about it by the client is worse. One error workflow across every client account means you get there first.

Solo operators with unattended jobs. Nightly syncs and scheduled reports are exactly the things nobody watches. A daily digest of failures is often more useful here than an instant alert.

Anyone whose workflows touch money or customers. A silently failing dunning sequence or lead router costs real revenue per day of silence, and those are precisely the workflows that run unattended by design.

Tired of finding out from the client?

30 minutes, free. Bring the workflows you rely on. You leave with a plan for error handling that you will actually keep switched on, whether you build it or we do.