n8n Error Handling and Retry Logic: 5 Silent Failure Patterns

n8n error handling and retry logic decide whether a broken workflow ever tells you it broke. On our own n8n instance, 7,754 workflow executions ran in the trailing 30 days. None of them were logged with a failed or crashed status. That doesn't mean nothing went wrong. It means n8n only reports the failures it can see.

Here's the short version. Retry On Fail and the error workflow are two separate systems in n8n 1.x. Retry handles a brief hiccup in a single node inside one execution, and the error workflow only fires after the whole execution has actually failed. Most silent failures slip between the two, because the run never fails at all. It finishes green with the wrong result.

Who this is for: small business owners and operations leads running n8n in production who need their automations to speak up when they break.

Rain Automation builds and runs n8n automations as part of its Custom CRM Build and automation consulting work, and every number in this guide comes from querying our own production instance, not from a survey.

Disclosure: Some links in this post, including links to n8n, are affiliate links. We may earn a commission if you sign up through them, at no additional cost to you.

Retry On Fail vs Error Workflow: How n8n Error Handling and Retry Logic Split the Work

Retry On Fail is a node-level setting that re-runs one node a few times inside the same execution. The error workflow is a workflow-level setting that starts a separate handler workflow after the execution has already failed. They cover different moments, and a run that never throws an error triggers neither one.

Retry On Fail lives in each node's Settings tab. Turn it on and you get two fields, Max Tries and Wait Between Tries (ms). The defaults are 3 tries and 1,000 ms, and the settings panel caps them at 5 tries and 5,000 ms. If the node still fails after the last try, its On Error setting decides what happens next.

That On Error setting has three options:

• Stop Workflow (the default). The execution fails, and if an error workflow is attached, it fires.
• Continue. The node passes an error item down its regular output and the execution keeps going as if nothing happened.
• Continue (using error output). The node gets a second output, and failed items travel down that branch so you can handle them on purpose.

The error workflow is set per workflow under Workflow Settings, in the Error Workflow dropdown. The workflow you pick must start with an Error Trigger node, which receives the failed execution's ID, URL, error message and the last node that ran, per the n8n Error Trigger documentation.

So here's the catch. Set a node to Continue and the execution can't fail, which means the error workflow never hears about it. (If you're still choosing a platform, our n8n vs Zapier vs Make comparison puts reliability data from 10,000+ runs side by side.)

Mechanism	Scope	When it acts	What it misses
Retry On Fail	One node	During the execution, before the node gives up	Permanent errors, failures hidden in a 200 response
On Error: Continue	One node	After retries run out	Everything, by design, because the run stays green
On Error: Continue (using error output)	One node	After retries run out	Whatever you forget to wire to the error branch
Error workflow + Error Trigger	Whole workflow	After the execution fails	Green runs with wrong output, manual test runs, workflows that never start

Pattern 1: No Error Workflow Attached (the Default State)

Every new n8n workflow ships with the Error Workflow setting blank, so a production failure gets logged in the executions list and nowhere else. If nobody opens that list, the failure is silent. The fix is one dropdown per workflow.

Build one handler workflow that starts with an Error Trigger node and sends a message somewhere a person actually reads. Then open each production workflow, go to Settings, and pick that handler in the Error Workflow dropdown. That's it.

We checked our own coverage. 26 of our 27 active production n8n workflows have a dedicated error workflow wired up to catch failures. That is 96 percent coverage on everything currently running. Across all 81 workflows on the instance, active or not, 58 have one configured.

And that one active gap is the whole point of this pattern. The setting lives inside each workflow, every new workflow starts blank, and nothing warns you when you activate one without it. Coverage drifts unless you check it.

If you self-host n8n on Postgres, you can measure your own coverage with a query against the workflow_entity table. This is the shape of the check we ran:

SELECT count(*) FROM workflow_entity
WHERE active = true
  AND settings::text LIKE '%errorWorkflow%';

Compare that to your total active count. On n8n Cloud you'll need to open each workflow's settings by hand, which is a good reason to make the dropdown part of your activation checklist. Our guide to self-hosting n8n in production covers the database setup that makes queries like this possible.

Pattern 2: An API Returns 200 OK With the Failure in the Body

Some APIs answer a failed request with HTTP 200 and a body like {"success": false}. n8n's HTTP Request node treats any 2xx response as a success, so the workflow moves on carrying a failure it can't see. You have to inspect the body yourself and route bad responses somewhere visible.

This is common with CRMs, email providers and messaging APIs. Slack's Web API, for example, returns HTTP 200 with "ok": false for most errors. To n8n, that's a perfectly healthy response.

Here's the fix, in order:

1. In the HTTP Request node's options, turn on Include Response Headers and Status so the status code sits next to the body.
2. Add an IF node right after it that checks the field that actually signals success (success, ok, or a returned record ID).
3. Send the false branch to a Stop And Error node with a message that names the record. That turns a quiet bad response into a real failure, and your error workflow fires.
4. If one bad record shouldn't halt the whole run, route it to a quarantine table instead and count it (see Pattern 3).

Now look at how often the opposite choice gets made. 73 nodes in our workflows have an explicit onError behavior instead of the default stop. 8 of those route the failure down a separate error-output branch rather than letting it fall through silently. The other 65 use plain Continue.

Overriding the default stop is common. Routing the failure somewhere a human will see it is not. Continue is sometimes the right call (an optional enrichment step shouldn't block a new lead from saving), but every Continue is a decision to accept silence, so make it deliberately. If you're connecting a CRM to outside tools, our post on custom CRM integration patterns covers the connection types where this check matters most.

Pattern 3: A Loop Skips Records Without Telling Anyone

A loop or batch can finish green after processing only part of its input. One bad record with Continue set, or an early exit inside Loop Over Items, and the rest of the batch quietly goes nowhere. The fix is a reconciliation count, expected items versus processed items, checked at the end of the run.

The n8n Community checklist The 9 ways n8n workflows die silently describes exactly this: a loop through 50 records hits a malformed record at #12 and never touches records 13 through 50. The execution log looks fine. The other 38 records just never happen.

A retry won't fix that. The malformed record will be malformed on the fourth try too.

What does fix it is counting. Put a Code node on the done output of Loop Over Items and compare what came in to what came out:

// Runs on the Loop Over Items "done" output
const expected = $('Get Records').all().length;
const done = $input.all();
const failed = done.filter(item => item.json.error).length;

if (done.length < expected || failed > 0) {
  throw new Error(
    `Reconcile failed: expected ${expected}, finished ${done.length}, ${failed} with errors`
  );
}
return [{ json: { expected, finished: done.length } }];

Throwing an error in a Code node fails the execution, which hands the problem to your error workflow with the counts in the message. Nodes set to Continue pass failed items along with an error field, so this check catches them too.

Better still, count at the destination. If records land in a database, a COUNT query filtered by the run's timestamp or batch ID checks what actually arrived, not what n8n thinks it sent. Our n8n PostgreSQL integration tutorial walks through the node setup for that query.

Pattern 4: Retry Settings That Mask a Permanent Failure

n8n's built-in Retry On Fail treats every error the same way. A 401 from an expired credential gets retried exactly like a 429 rate limit or a 503 outage, even though no number of retries will fix the 401. Retry only failures that can clear up on their own, and fail fast on everything else.

Here's what retry configuration looks like on a working instance. 61 individual nodes across our production n8n workflows have retry-on-fail turned on. The most common setting waits 5 seconds between attempts, with 3 seconds the next most common.

Wait Between Tries	Max Tries	Nodes
5,000 ms	not recorded separately	26
Not set (n8n defaults)	not set	11
3,000 ms	not recorded separately	8
1,000 ms	not recorded separately	6
2,000 ms	3	5
5,000 ms	5	3
2,000 ms	2	1
3,000 ms	3	1
Total		61

The data shows something worth noticing. The most common wait, 5,000 ms, is also the highest value the settings panel allows. Built-in retry is a short-window tool. Three tries five seconds apart covers about 10 seconds, it never backs off exponentially, and it doesn't read a Retry-After header. A rate limit that asks you to wait 60 seconds will outlast it every time.

Say a nightly CRM sync hits an expired OAuth token. With Max Tries at 3 and 5 seconds between tries, the node makes three calls that were never going to work, then gives up. The 10-second delay isn't the damage. The damage comes when that node is also set to Continue, because then the 401 becomes an error item, the run finishes green, and the sync quietly does nothing every night until someone notices the CRM is stale.

So split your errors by class:

• Retry these: timeouts, 429, and selected 5xx codes. n8n's own retry template with exponential backoff and jitter treats 408, 409, 425, 429, 500, 502, 503 and 504 as retryable and holds other 4xx responses for manual review. Treat that as a sensible starting policy, not a universal rule.
• Don't retry these: 400, 401, 403, 404. Stop, alert, and fix the input or the credential.
• Be careful with POSTs. If the first request actually succeeded but timed out on the way back, a retry can create a duplicate contact or a second invoice. Use an upsert or an idempotency key wherever the API supports one.

For longer waits, build the backoff yourself. Route the error output to an IF node that checks the status code, send retryable codes through a Wait node and back to the request with an attempt counter, and send everything else (or anything past the attempt cap) to Stop And Error. Our n8n CRM integration hub has three CRM workflows where that loop slots in cleanly.

Pattern 5: Nobody Verifies the Error Workflow Itself

An error workflow you've never seen fire is an assumption, not a safety net. The Error Trigger node only runs when a workflow fails during an automatic execution, never during a manual test, so clicking Test workflow proves nothing about your alerts. You have to force a real production failure and confirm the message arrives.

There's a common assumption that the Error Trigger node is the main error-catching tool, something you'd see in most workflows. It isn't. Only 3 of our 81 n8n workflows use a dedicated Error Trigger node. The rest of our error handling runs through the workflow-level error workflow setting instead.

That's how n8n is designed. The Error Trigger is the start node of the handler, not something you add to every workflow. A small number of handlers can serve dozens of workflows through the dropdown from Pattern 1. Which also means those few handlers deserve the most scrutiny, because when one breaks, every workflow pointing at it goes quiet at the same time.

Handlers break in boring ways. The send step uses an SMTP credential that expired, or the alert lands in a channel nobody watches anymore. (If your alerts go out by email, our guide to n8n emails that send but never arrive covers the delivery side.) And if the handler itself errors, there's no second layer unless you build one.

Test it the way production fails:

1. Create a tiny workflow with a Schedule Trigger and a Stop And Error node that says "Scheduled alert-path test."
2. Point its Error Workflow setting at your handler and activate it.
3. Confirm the message reaches the person who's supposed to act on it, then leave it running weekly so a broken alert path shows up as a missing test message.

There's one more gap no error workflow can cover. A workflow that never starts (deactivated, a cron expression dropped, the instance down) can't fail, so nothing fires. For critical workflows, add a heartbeat: the last node pings an external monitoring service on every successful run, and that service alerts you when the ping goes missing. On the n8n Community production monitoring thread, forum member Dima (posting as dima_automation) split the problem into failed runs, runs that produced nothing and runs that never started, because "one alerting setup almost never covers all three." Michael Frostbutter, who posts in that thread with the n8n Team badge, made the same three-way split and added that time-to-detection is very different for each.

n8n Error Handling and Retry Logic: Which Failure Gets Which Response

Match the response to the failure class. Transient errors get bounded retries, permanent errors stop and alert, bad-but-successful responses get validated and quarantined, and batch failures get counted and reconciled. Using one setting for everything is how silent failures happen.

Failure class	Example	Correct response	n8n 1.x setting
Transient	Timeout, 429, 502, 503	Bounded retry with backoff	Retry On Fail for short blips, a Wait node loop for longer waits
Permanent	401 expired credential, 400 invalid input, changed API contract	Stop and alert, no retry	On Error: Stop Workflow plus an error workflow
Non-throwing bad response	200 OK with "success": false	Validate and quarantine	IF node plus Stop And Error, or error output to a review table
One item fails in a batch	One malformed record out of 50	Capture, count, reconcile	Continue (using error output) plus an end-of-run count check
Webhook accepted, work unfinished	Caller gets a 200, a later step fails	Respond fast, verify downstream separately	Respond to Webhook early, idempotency key, status check
Alert path fails	Expired SMTP credential in the handler	Test delivery on its own, assign an owner	Scheduled forced-failure test plus a heartbeat

The webhook row trips people up most. Slack's Events API expects a 2xx response within 3 seconds and retries failed deliveries 3 times with exponential backoff, so a slow workflow can process the same event four times. On n8n Cloud, a webhook that doesn't respond within 100 seconds fails with HTTP 524, per n8n's webhook troubleshooting docs. The pattern is the same either way. Respond immediately, then do the slow work and verify it separately. Our n8n webhook response modes guide explains when to use each response mode.

Why More Alerts Won't Fix Silent Failures

Most advice on silent failures ends at "send a Slack alert." That catches hard failures, but a silent failure by definition doesn't throw an error, so the alert has nothing to fire on. The real fix is output verification, which means checking that the destination actually holds what the workflow was supposed to produce.

This is where we part ways with the forum checklists. Alerts are necessary, but they're the last step, not the fix. In the same n8n Community monitoring thread, Rory Hayes, who is building Maintain Flow (a tool for agencies maintaining client automations), wrote that teams "stop at 'send a Slack alert' and still do not have an operating loop for what happens next." Without one, alerts become noise, and noisy channels get muted.

And the worst silent failures never alert at all. One example shared on the n8n Community describes a workflow that ran for three weeks with all-green executions while sending empty reports. Nobody noticed until someone opened the output by hand. No amount of alerting would have caught it, because nothing failed.

We call our version of output verification the Did-It-Land Check. It's three questions you ask of any workflow that matters, in this order:

1. Did it produce what it promised? (Declared expectations.) Each run states what it must produce (at least one row, a report that isn't empty, a CRM record ID) and throws a Stop And Error when it doesn't.
2. Does today look like a normal day? (Historical baselines.) A nightly import that normally writes a few hundred rows and today wrote zero has failed, even with a green status. Compare today's count to a normal range. Dima makes the same point in the monitoring thread: "If yesterday pulled 400 rows and today pulled 0 with no error, that's the signal, not the green checkmark."
3. Is it actually in the destination? (Destination reconciliation.) Query the CRM, database or inbox after the run and confirm the records exist. This is the only check that proves the business outcome happened.

Questions 1 and 2 run inside the workflow. Question 3 runs as a separate scheduled workflow, so it still works when the original one breaks in a way nobody planned for.

The nice side effect is that your existing alerts get better. Once an empty report throws a real error, the error workflow you already built finally has something true to say. The same idea applies to CRM deal stage notifications, where the alert is only as good as the condition behind it.

What We Found Auditing Our Own n8n Instance

We queried the Postgres database behind our production n8n instance on October 17, 2026, counting every workflow, node setting and execution record it holds. Error workflow coverage on active workflows was high, but most node-level overrides chose plain Continue over a dedicated error branch.

The method was simple. We ran count queries against n8n's own workflow_entity and execution_entity tables, reading node settings straight from the stored workflow JSON. We're publishing aggregate counts only, with no workflow names.

On our own n8n instance, 7,754 workflow executions ran in the trailing 30 days. None of them were logged with a failed or crashed status. That's about 258 executions a day.

That zero needs its caveat stated right next to it. Our instance keeps execution data for 720 hours (the EXECUTIONS_DATA_MAX_AGE setting), so 30 days is the entire history available to check, and nothing older could be counted. n8n's own default prunes even sooner, at 336 hours, per the execution data docs. The figure also counts only what n8n itself marks as failed. With 65 nodes set to plain Continue, a green status is exactly what a silent failure would look like, which is why this guide spends more time on verification than on status codes.

Check	Result	Related pattern
Executions in the trailing 30 days	7,754 (about 258 per day), 0 logged as failed or crashed	Status alone isn't proof
Active workflows with an error workflow	26 of 27 (96%)	Pattern 1
All workflows with an error workflow	58 of 81	Pattern 1
Nodes with an explicit onError setting	73 (65 Continue, 8 error output)	Patterns 2 and 3
Nodes with Retry On Fail enabled	61 (most common wait 5,000 ms)	Pattern 4
Workflows with an Error Trigger node	3 of 81	Pattern 5

Compare the rows and a pattern appears. The workflow-level safety net is nearly complete, while node-level decisions lean heavily toward Continue. That's the gap where silent failures live on most instances, and it's the first place to look on yours. You can see how we approach finished builds on our case studies page.

Where Should You Start Fixing Silent Failures This Week?

Start with the cheapest checks. Attach an error workflow to every active workflow, force one real failure to prove the alert arrives, then review every node set to Continue. After that, add count checks to the workflows that touch revenue.

1. List your active workflows and confirm each one has an Error Workflow selected. This takes minutes.
2. Build the scheduled forced-failure test from Pattern 5 and watch the alert land.
3. Search for nodes set to Continue. For each one, either justify it or switch it to Continue (using error output) with a real handler.
4. Find your HTTP Request nodes that call APIs known to return 200 on failure, and add an IF check on the body.
5. Run the Did-It-Land Check on the two or three workflows where a skipped record costs you a lead or an invoice, starting with a reconciliation count at the destination.

If you'd rather hand this off, we run this kind of audit and rebuild workflows around a CRM that fits the way your business actually works. Get in touch and tell us what your workflows are supposed to do. If the real problem is a CRM your automations keep fighting, our Custom CRM Build service is the place to start.

Frequently Asked Questions

What is the difference between retry on fail and an error workflow in n8n?

Retry on fail re-runs a single node inside the same execution, while an error workflow is a separate workflow that starts after the whole execution fails. Retry handles brief glitches like timeouts. The error workflow handles notification. A run that finishes green with bad data triggers neither one, so you need output checks too.

Why does my n8n workflow show success but not actually do anything?

Your workflow shows success because n8n only marks a run as failed when a node throws an error and stops. An API that returns 200 with a failure in the body, a node set to Continue, or an IF branch that matches nothing will all finish green. Validate outputs and count results to catch them.

How do I set up an error workflow in n8n?

Create a workflow that starts with an Error Trigger node and ends with a notification step, such as email or Slack. Then open each production workflow, go to Settings, and select it in the Error Workflow dropdown. Test it with a scheduled real failure, because manual test runs never trigger it.

How many times does n8n retry a failed node by default?

n8n makes up to 3 attempts by default, waiting 1,000 milliseconds between them, once you turn on Retry On Fail in the node's Settings tab. Retry is off until you enable it. You can raise Max Tries to 5 and Wait Between Tries to 5,000 milliseconds, which are the limits in the settings panel.

Does n8n's retry on fail work for every type of error?

No, retry on fail only helps with errors that can clear up on their own, like timeouts, 429 rate limits and 503 outages. It retries a 401 expired credential or a 400 validation error the same way, which wastes calls and delays the alert. It also can't see failures hidden inside a 200 response.

What does the Error Trigger node in n8n actually catch?

The Error Trigger node catches executions that fail during automatic runs, such as schedule, webhook or app triggers, and passes along the execution ID, error message and last node executed. It doesn't fire on manual test runs, on nodes set to Continue, or for workflows that never started in the first place.

Can an n8n loop skip records without failing the whole workflow?

Yes, a loop can skip records and still finish green, especially when a node inside it is set to Continue on error. The failed items pass through as error items and the run counts as a success. Compare the number of input records to the number saved at the end of the run, and fail on a mismatch.