Safe retries in n8n: which errors to retry, which to stop, and where the rest go

Honesty note — read this first. No lab test was run for this article. The retry patterns below are proposed, documentation-based guidance — they describe how n8n’s settings and common API behaviour are designed to work, not results from a test run on this site. No workflow was executed, no failure counts were measured, and no timings were recorded for this guide. If you follow a pattern here, test it with fictional data in your own test setup before you use it on real work. All examples, job IDs, names and numbers in this article are fictional.

The problem: retrying everything is as bad as retrying nothing

A workflow sends 40 orders to a supplier’s API. Thirty-eight go through. Two fail.

That is the moment every n8n retry failed workflow question starts. Retry everything blindly, and the two failures might be duplicate orders — the customer gets charged twice. Retry nothing, and two real orders quietly disappear until a customer asks where their order is. Retry the wrong ones, and a workflow that hit a bad API key (401) hammers the API, gets the account locked, and still fixes nothing.

Most n8n setups pick one of the first two by accident. The default, “stop on the first error”, is safe but throws away work. The other common setup, turning on a retry and hoping, can repeat a payment or a CRM write that should only happen once.

The fix is a decision you make before the workflow runs: for each kind of failure, decide in advance whether to retry, stop, or set it aside for a human. This guide is that decision, plus the place the rest go — the n8n retry failed workflow dead letter queue pattern. Two guides on this site are the background: n8n Rate Limit: Fix HTTP 429 with Retry-After and n8n Error Workflow: Setup + Why It Misses Failures. This one sits between them: which failures deserve another try, and what happens to the ones that don’t get one.

Which errors to retry in n8n: the decision table

When an HTTP Request node fails, n8n shows an error message. Useful, but not what to base your decision on. Messages vary between APIs. Status codes do not. Use the status code.

Two things in that table surprise most people. First, 400, 401 and 403 are never retryable. A retry only helps when the problem might be gone by the next attempt. A bad request will still be bad in five minutes, and an expired API key will still be expired. Retrying those wastes API calls and can trip an account lockout on 401s. The right response is an alert that says “fix the credential” or “fix the data”, not a loop.

Second, a timeout is the hardest case. With a 500 you know the request failed. With a timeout you know nothing — it may have been processed, or never arrived. Retrying a payment after a timeout can create a duplicate, so retry once, then queue it for a human. That is the whole point of the queue below.

n8n Retry On Fail: what the built-in retry can and cannot do

Every n8n node has a Settings tab with Retry On Fail. Turn it on and two fields appear: Max Tries and Wait Between Tries. As documented for n8n 2.x, Max Tries runs from 2 to 5 and defaults to 3, and Wait Between Tries defaults to 1,000 ms and tops out at 5,000 ms. Even at the maximum, that is five attempts five seconds apart — about 20 seconds of cover in total.

That window fits one case: a brief glitch. An API times out once, then works. A server returns a 502 now and then. A per-second rate limit clears in a moment.

It does not fit the rest. Three limits matter:

1. It cannot wait long enough for a real rate limit. An API with a 60-second cooldown will still be rate-limiting you when the built-in retry gives up. For that, you need a Wait node and the Retry-After header — see the 429 guide.
2. It retries everything, including the errors you should never retry. It has no status-code check. It retries a 400 just as happily as a 503.
3. A retry re-runs the whole node. If an HTTP Request node is processing 100 items and item 87 fails, the retry sends the first 86 again. For a read, that is harmless. For sending email, creating orders, or writing to a database, it can mean duplicates. Before enabling retries on a write, make sure the target API deduplicates — for example, by accepting a unique order ID — or process one item at a time.

My rule of thumb, proposed not tested: turn Retry On Fail on for nodes that call external services, like HTTP Request or Google Sheets, and leave it off for internal nodes like IF, Edit Fields and Code. A retry cannot fix a wrong expression or a bad field name.

How to retry a failed execution from the Executions tab

Sometimes you do not need a retry pattern at all. You just need to run the failed execution again. n8n lets you do that from the Executions tab, reusing the exact input data from the original run. You do not need to resend the webhook, resubmit the form, or wait for the next scheduled run.

Open the failed execution and use the retry option. n8n gives you two choices:

• Retry with original workflow. Runs the execution again using the workflow exactly as it was when it first ran. Use this when the failure was temporary, like a rate limit or a service that was briefly down, and the workflow itself did not need changing.
• Retry with currently saved workflow. Runs the same input data through the latest saved version of the workflow. Use this after you have fixed the broken node, to confirm the fix against the data that originally failed.

Both reuse the original trigger data. The retry appears as a new entry in the Executions list.

One warning before you click it: do not retry a write blindly. If the failed run may already have created an invoice, sent a message, charged a card, or updated a CRM, check the destination first. A retry can duplicate the action even when n8n recorded the workflow as failed later in the run. If you are not sure the first attempt failed cleanly, check first, then retry.

n8n Retry On Fail vs error workflow: what is the difference?

n8n has three things with “retry” or “error” in the name, and they do different jobs. Mixing them up is how a workflow retries a 401 four times and then never alerts anyone.

Retry On Fail — node level. A setting on one node’s Settings tab. When the node fails, n8n waits briefly and runs it again. It fits a brief glitch. It knows nothing about the status code, so it retries a 400 just as happily as a 503, and it cannot queue a failed item. Use it only where a brief glitch is likely, and keep attempts low.

Error workflow — execution level. A separate workflow starting with the Error Trigger node, running when a linked workflow fails. It alerts and it logs. It cannot re-run the failed item. And — as the error-workflow guide shows in its lab test on n8n 2.41.3 — it never fires for manual runs, “Continue” nodes, or a polling trigger that silently stops. It is your safety net, not your retry logic.

Job-level retry — the pattern in this guide. Not a setting, but a loop you build inside the workflow: make the request, check the status code, decide (retry / stop / queue), wait if retrying, and try again — with a counter that stops the loop after a fixed number of attempts. It is the only one of the three that can follow the decision table, because it is the only one that looks at the status code first. It takes more nodes to build, and it is worth it wherever a failed item matters — orders, leads, invoices, anything a customer would notice missing.

Remember it this way: Retry On Fail handles a glitch. The error workflow handles the alarm. The job-level retry handles the decision.

There is one more link between the first two that catches people out. The error workflow only runs when the execution actually fails. If you set a node’s On Error to Continue, the error is swallowed, the execution ends as successful, and your error workflow never hears about it. Configure Retry On Fail and On Error together, on purpose — not one at a time.

How to retry: bounded backoff, jitter, and Retry-After

Honour Retry-After when the API gives you one. Some APIs send a Retry-After header with a 429 response, telling you in seconds how long to wait. If it is there and valid, wait at least that long. The full detail is in the 429 guide.

Use bounded backoff when there is no Retry-After. Backoff means waiting longer after each failure: 2 seconds after the first, 4 after the second, 8 after the third. Bounded means you cap both the wait and the total attempts. A proposed starting point, not a tested result: base wait 2 seconds, doubling each time, capped at 60 seconds, maximum 4 attempts in total.

Add jitter. Jitter is a small random extra wait — a second or less — added after the backoff wait, so ten workflows that fail together don’t all retry at the same instant and cause another 429. Add it after the Retry-After floor, never before it. The Retry-After value is a minimum, not a suggestion.

The most important rule: only retry a write when repeating it is safe. A GET request is safe to repeat. A POST that creates an order, sends an email, or charges a card is not — unless the API supports an idempotency key, a unique ID telling the API the second identical request is a repeat, not a new order. If you cannot confirm a write is safe to repeat, send it to the dead-letter queue and let a human decide.

n8n dead letter queue: where the rest go

A dead-letter queue is a list of items that failed and will not be retried automatically. Not a bin. A waiting room with a name on every chair.

When an item has used up its retries, or fails with a status you never retry (400, 401, 403), the workflow writes one row to a table — a Google Sheet, a database table, or n8n’s own Data Table — and stops touching it. A human fixes the cause and re-runs it by hand.

Every row needs the same six fields — workflow, item ID, error, attempt count, first failed at, next action — or the queue is just a list of errors nobody can act on.

The 401 row was never retried — attempt count 0 — because retrying it would have been pointless. The timeout row says “check if the order exists first”: the duplicate check a blind retry would have skipped.

Three habits make it work. Write to the queue before you send any alert — if the alert fails (a broken Slack credential, the exact failure the error-workflow guide describes), the row is still there. One row per item, not per attempt. And review it on a schedule — once a day is enough for most solo setups. A queue nobody reviews is just a slower way to lose work. When you review it, mark each row resolved or abandoned, and say why. A row with no decision is still a failure waiting to be noticed.

A queue is worthless without a way to drain it. Once a day, work the oldest rows first. Fix the cause, then re-run the item by hand — or, for rows you have already fixed the cause for, retry them from the Executions tab using the currently saved workflow. After a few re-runs, if the item still fails, mark it abandoned and write down why. Abandoned is a decision. Ignored is not.

Putting it together: one flow, three exits

Take a fictional daily lead import. Read one item, keep its ID with it, and send the request with “Include Response Headers and Status” turned on, so the workflow can see the status code and the Retry-After header. Then check the status code.

• Success (200–299) moves on to the next item.
• Retryable (429, 503, 500, 502, 504, timeout) waits and tries again if attempts are left, or goes to the dead-letter queue if they are used up.
• Not retryable (400, 401, 403, 404) does not retry. Write the dead-letter row and alert immediately.

Finally, alert once: the error workflow, or a single alert node, tells you the queue has a new item.

If the failed item is sensitive — a payment, a contract action, a customer message — do not re-run it automatically from the queue either. That is a human decision, the same judgement the human-in-the-loop tutorial teaches: pause, show a person the exact details, and only then act. An approval step before the re-run is slower than an automatic retry, and it is the right kind of slow.

What this guide does not cover

Duplicate prevention. Retrying safely is only half the job. If a webhook delivers the same event twice, or a retry runs after the first attempt already succeeded, you need a check that stops the second run from doing the work again. That is a separate problem, and it has its own tested guide: n8n Webhook Duplicate Prevention. Read it before you retry any webhook that writes data.

Silent failures. None of the retry settings in this guide help when a workflow never runs at all. A polling trigger that quietly stops produces no error, no failed execution, and no alert — so there is nothing to retry. That needs a heartbeat check, not a retry loop: how to catch a polling trigger that just stops.

Webhook authentication. A retry loop does not make an unauthenticated webhook safe. If anyone who finds your webhook URL can fire it, retries only repeat the problem faster. Webhook authentication is a separate, not-yet-published guide on this site.

Backups. If the workflow itself is lost or broken, no retry setting brings it back. Keep a backup of your workflows before you need one.

FAQ: n8n retry failed workflow

Does n8n retry failed workflows automatically?

No — not as a whole. Only the nodes where you turn on Retry On Fail retry automatically, and only for a few seconds. A failed run is not retried as a whole unless you retry it from the Executions tab, or you build a retry loop yourself, as this guide describes.

How do I rerun a failed execution in n8n?

Open the Executions tab, open the failed run, and use the retry option. Retry with original workflow reruns it exactly as it was. Retry with currently saved workflow runs the same input through your latest saved version — use that one after you have fixed the broken node. Both reuse the original trigger data, so you do not need to resend the webhook or resubmit the form.

Which errors should I never retry in n8n?

400, 401 and 403. A bad request will still be bad in five minutes, and an expired API key will still be expired. Retrying them wastes API calls and can trip an account lockout on 401s. Fix the data or the credential first, then re-run by hand.

What is a dead letter queue in n8n?

A list — a sheet, a database table, or a Data Table — where failed items wait after they have used up their retries. Each row keeps the workflow, the item ID, the error, the attempt count and the next action, so a human can fix the cause and re-run the item. Without it, a failed item either blocks the whole workflow or disappears silently.

Still stuck on retries?

Get a $29 quick fix or $79 full fix by email: n8n workflow review by email. If you haven’t tried n8n yet, try n8n Cloud.