That fourth layer is the one that costs money when it's missing, so this article spends real time on it. If you're new to the tool, start with What is n8n?, and if the failures you're chasing happen at the front door, read n8n webhooks explained alongside this.
In short
- Layer 1 — node:
Retry On FailandOn Erroron the nodes that touch the outside world (n8n Docs). - Layer 2 — workflow: link an error workflow in settings; it must start with the Error Trigger node (n8n Docs).
- Layer 3 — deliberate:
Stop And Errorwhen data is invalid, so failures are loud instead of silent (n8n Docs). - Layer 4 — sweeps: scheduled reconciliation that finds stuck and skipped records.
- The mindset: an execution succeeded when the business outcome happened, not when the nodes finished.
Why this stops being optional
A workflow that runs ten times a week can be repaired by the person who built it. A workflow that runs thousands of times, across many locations, cannot — because by the time a human notices, the damage is a week old and distributed.
For scale context: MitHub's pioneers have built AI voice campaigns that ran across 28 live branches of a multi-location lending business, including a 10-branch pilot with 13,159 AI calls. At that volume, "I'll check the executions tab" is not an operating model. Error handling is the difference between a system that tells you it's broken and one that waits for a customer to tell you.
Layer 1: node settings
Open any node's settings panel and you get a short list of options that change failure behaviour. n8n documents these as (Work with nodes):
| Setting | What it does | When to use it |
|---|---|---|
| Retry On Fail | Reruns the node until it succeeds | Flaky external APIs, rate limits, transient network errors |
| On Error → Stop Workflow | Halts the whole execution | Anything where continuing would corrupt data |
| On Error → Continue | Moves to the next node despite the error | Optional steps: an enrichment that's nice to have |
| On Error → Continue (using error output) | Continues, passing error information down a separate branch | When you want to handle the failure: log it, quarantine the record, alert |
| Always Output Data | Returns an empty item when the node returns nothing | Prevents a branch from dying quietly on an empty result |
| Execute Once | Runs once, using the first item | Guard against accidental fan-out |
The one worth learning properly is Continue (using error output). It converts an exception into a routable path: the happy path writes the record, the error path writes a dead-letter row and pings a channel. That's how you make failures visible without stopping the other 199 items in the batch.
A rule of thumb: retries belong on idempotent steps. Retrying a "create record" call three times can create three records. If a step isn't safe to repeat, don't retry it — catch it instead.
Layer 2: the error workflow
n8n lets you nominate an error workflow per workflow. When an execution fails, that workflow runs automatically, and it must begin with the Error Trigger node; the same error workflow can serve many workflows (Handle errors gracefully). You select it in workflow settings, where the field is documented as "Select a workflow to trigger if the current workflow fails" (Configure workflow settings).
The Error Trigger hands you real diagnostic data. For errors after the trigger has run, n8n documents fields including the execution id, the execution URL, the error message, the last node executed, and the workflow id and name; errors inside a trigger node arrive in a different shape under a trigger object (Error Trigger).
One documented constraint saves an hour of confusion: you can't test an error workflow by running a workflow manually — the Error Trigger only fires when an automatic workflow errors (Error Trigger). To test it, publish a small workflow that fails on purpose.
The MitHub alert format
Most alerting fails not because the message didn't send but because nobody could act on it. An alert should answer five questions in the first two lines, because it will be read on a phone by a tired person:
- What broke? Workflow name, in plain language ("Inbound lead routing").
- Where? The last node executed.
- Which record? The business identifier — lead ID, customer name, branch — not just the execution ID.
- How bad? Is one record affected, or is the queue backing up?
- What now? The execution URL, and the one action the reader should take.
Anything else is noise. An alert that says "Workflow 47 failed" trains people to ignore alerts, which is worse than having none.
Route alerts by severity, not by habit
Send everything to one channel and everything gets muted. A simple split, decided inside the error workflow:
- Blocking (money, customers, compliance) → the on-call person, immediately.
- Degraded (an optional enrichment failed, a report is late) → a team channel.
- Noise (a known flaky endpoint that retries successfully) → a log table only.
Layer 3: fail on purpose
The Stop And Error node lets you fail an execution deliberately, with either a custom error message or an error object, and it sends that information to the error workflow (Stop And Error).
Use it as a validation gate near the top of every workflow that receives outside data:
- Missing a required field → stop with "Lead 88213 has no phone or email; source: website-form".
- A value outside an expected set → stop, don't guess.
- A record that shouldn't be here at all → stop, and say why.
This feels counterintuitive the first time. A workflow that stops looks worse on the dashboard than one that quietly processes rubbish. It is dramatically better: garbage that flows through a system is discovered later, by a customer, at higher cost.
Layer 4: the sweep, and the failure nobody sees
Here's the uncomfortable part. Every layer above catches things that throw an error. The expensive failures usually don't:
- The CRM returned 200 and an empty body; the field never updated.
- An IF node sent every item down a branch that does nothing.
- A callback from an external system never arrived, so the record sits in "processing" forever.
- The workflow was unpublished during maintenance, and the events simply went nowhere.
- Executions queued behind a concurrency limit and finished far later than anyone assumed — on n8n Cloud, executions beyond the plan's concurrency limit queue and are processed in FIFO order, and production executions from webhooks and trigger nodes are what count against it (Understand concurrency).
None of these produce a red execution. All of them produce an unhappy customer.
The dead-letter pattern
Give every record a status field that only your workflows write to: received → validated → enriched → routed → actioned. Two things follow immediately:
- Any failure lands somewhere. On the error branch, write the record, its last known status, the error text and a timestamp into a dead-letter table — a database table, a sheet, or a CRM object. Nothing disappears.
- Stuck is detectable. A record in
enrichedfor 40 minutes is not an error; it's a fact you can query.
The reconciliation sweep
Build one scheduled workflow per process. Every 15 or 30 minutes it asks three questions:
| Question | Query | Action |
|---|---|---|
| What's stuck? | Records past their expected status age | Route with a default, flag for review |
| What's missing? | Count of inputs today vs count of actioned records today | Alert on a gap above a threshold you choose |
| What's in the dead-letter table? | Rows added since the last sweep | Summarise into one message, not one per row |
The second question is the one that matters. It compares the front door to the back door — how many leads arrived, how many got an outcome — and it's the only check that catches "everything ran, nothing happened."
Note that on n8n Cloud, error executions and sub-workflow executions are documented as operating under separate constraints from production concurrency (n8n Docs), which is useful to know when designing a sweep that itself calls sub-workflows.
Workflow settings worth setting once
From the settings documentation, three choices have outsized effects:
- Save failed production executions — keep them. Debugging without the failed run is guesswork.
- Save execution progress — n8n describes this as saving execution data for each node so that "the workflow resumes from where it stopped in case of an error." Valuable for long, expensive chains; it costs storage.
- Timeout Workflow — cancel executions after a set duration, so a hung call doesn't hold a slot forever.
Also set Execution order deliberately. The settings page documents v1 as the recommended option, running multi-branch workflows sequentially, versus the legacy v0 level-by-level behaviour. On a workflow where one branch must finish before another starts, this is a correctness issue, not a preference.
Where humans belong
Not every failure should be auto-recovered. Some should stop and wait for a person: a refund above a threshold, a message about to be sent to a large customer, a deletion. Designing those pause points is its own skill, covered in human in the loop.
The reverse is also true: don't route recoverable failures to humans. If a person is manually retrying the same API three times a week, that's a missing retry setting, not a job.
The production readiness checklist
Before a workflow handles anything that matters:
- Every external-call node has an explicit On Error choice — not the default because you never opened the panel.
- Retry On Fail is on for flaky, idempotent steps only.
- An error workflow is linked, and it has been tested with a deliberate failure.
- Alerts follow the five-question format and are routed by severity.
- Every record has a status field and a dead-letter destination.
- A sweep runs on a schedule and compares inputs to outcomes.
- Someone is named as the owner of the alerts. Not a team. A person.
- Once a week, a human traces three real records end to end.
That last habit is the one that keeps the rest honest, and it comes straight from the Operate chapter of the Faculty of Revenue Reverse Engineering: observe, measure, adjust. Reliability isn't a node you add. It's a loop you run, and it's what separates an automation demo from a system a business can depend on — the same argument made in systems thinking for AI automation.