The settings, at a glance.
For an HTTP Request node, open Settings, enable Retry On Fail, then choose Max Tries and Wait Between Tries. Start with a request that is safe to repeat. A retry does not make a write safe by itself.
Illustrative setup for a read request: Max Tries 3 and Wait Between Tries 1000 ms. These are example values, not a policy for every API. Check the provider’s limits and test a deliberate failure on your own n8n version.
Settings reference checked 14 September 2026 against the current n8n documentation. The example has not been executed against your instance.
- Settings → Retry On Fail
- Enable another attempt when the node fails. Check whether repeating the request is safe first.
- Max Tries
- Set a small attempt limit. Confirm the attempt count in the execution log for the node version you use.
- Wait Between Tries (ms)
- Use milliseconds. For example, 1000 means a one second wait. This is a fixed interval, not adaptive backoff.
- On Error
- Choose how an exhausted failure should be handled, and test the selected output branch with a failing request.
Name the failure before you retry it.
A request can fail in ways that mean different things. A refused connection means nothing happened. A 429 means the service saw you and asked you to slow down. A 500 means it may or may not have done the work. A timeout means you do not know.
A retry is only safe when the failure implies the work did not happen, or when repeating the work is harmless. Turning on retries without answering that question is how a workflow sends the same message twice.
So the first design step is to sort the failures the workflow can see into three groups: safe to repeat, never repeat, and unknown. The settings below are applied differently to each group.
Understand what Retry On Fail actually does.
Nodes that support retries expose settings such as Retry On Fail, a maximum number of tries, and Wait Between Tries (ms). When enabled, a failing node reruns up to that limit with a pause between attempts. In the versions I run, the pause is a constant, not a curve that grows on each attempt. The rate limits documentation describes the current behavior.
The retry repeats the node with the same input items. It does not look at the status code, so a 400 caused by bad data is retried as eagerly as a 503. Even for a read, repeating a bad request can waste quota. For writes, define the failure and idempotency policy before enabling retries.
The On Error setting controls how execution proceeds when a node fails. Use Stop Workflow when the failure should stop the run, or an error output when the workflow needs to handle it explicitly. The interaction with retries and the output data can depend on the node and version: test an exhausted retry and inspect the actual output rather than assuming it contains a successful result.
Slow down before you get told to.
The HTTP Request node has a Batching option with Items per Batch and Batch Interval in milliseconds. It sends items in groups and waits between groups. That is the simplest way to stay under a rate limit when a workflow receives many items at once. See the HTTP Request node documentation.
When each item needs several nodes rather than one request, use the Loop Over Items node with a small Batch Size and a Wait node inside the loop. The loop returns to the top after each batch until the items are exhausted, and the Wait node sets the pace.
Neither option knows the API’s actual limit. Read the service’s documentation for the limit per second or per minute and per key, then set the interval with room to spare. A limit shared across several workflows is consumed by all of them, so the safe pace for one workflow depends on what else is running.
Treat a 429 as an instruction, not an error.
A 429 often comes with a Retry-After header saying how long to wait. A fixed retry interval ignores it. To honor it, route the error output of the request node to a Wait node whose duration comes from the header when present and from a growing default when it is not, then loop back to the request.
Grow the default on each pass, and cap the number of passes. Doubling from one second with a limit of five or six attempts covers most bursts without hammering a service that is already struggling. Add a small random jitter so several executions that failed together do not all retry in the same second.
Record each backoff in a log field or a Data Table row. When a rate limit is hit regularly, the fix is usually in the batching pace or the workflow design, not in more retries.
Check before you repeat a side effect.
Before a node that creates, sends, or charges, the retry question changes. If the first attempt might have succeeded, a blind retry duplicates it. Use a stable action key and explicit states for prepared, attempted, confirmed and uncertain work. Coordinate who may attempt the action, then record or reconcile the result.
Use the same idempotency key when the provider explicitly guarantees deduplication for that operation. A client reference field is not equivalent unless the provider enforces that behavior. A lookup before a write is not atomic: two workers can both find no record and both proceed. Use an atomic claim or a unique action record to coordinate workers, and reconcile an uncertain external result before allowing another attempt. Local coordination alone does not guarantee exactly one effect in an external system.
The duplicate actions guide walks through this with a small model you can run, including the case where the response never arrives and the outcome is unknown.
Set timeouts you can explain.
The HTTP Request node’s Timeout option limits how long the node waits for the response headers. Without it, a stalled connection can hold an execution for a long time and, on a busy instance, hold a worker with it.
Pick a value from the service’s normal response time with a wide margin, not from a guess. A timeout that is too short creates failures out of ordinary slowness, and each of those may become a retry that adds load to the service you are waiting for.
A timeout is an unknown outcome, not a failure. Route it to the same uncertain path as a missing response: hold new attempts for that action key, and reconcile later by reading the destination.
Send failures somewhere a person will see them.
Each workflow can name an error workflow in its settings. That workflow starts with an Error Trigger node and receives details of the failed execution. See the Error Trigger documentation. One error workflow can serve many workflows.
Use it to post the workflow name, the execution id, and the failing node to a channel the team reads, and to write a row to a failures table. A retry that exhausts its tries and stops the workflow ends up here. A retry that succeeds on the third attempt does not, so log those inside the workflow if the pattern matters.
The error workflow is for visibility, not recovery. Recovery belongs in the workflow itself, on the error output branch, where the failed items are still available.
Need a workflow that can recover?
A workflow review identifies where requests fail, which actions can repeat safely, and how unresolved outcomes reach an owner. The deliverable is a failure map, prioritized fixes and a proposed implementation scope.
Discuss n8n automation and repairs with the tools and one sanitized example of the failure.
Know when to queue instead.
Retries assume the service will be fine in a few seconds. When it is down for an hour, when the volume exceeds a daily limit, or when the work must be done in order, retries turn into a stalled execution or a pile of failures.
A queue separates receiving from processing. The receiving workflow writes each job to a Data Table or a database with a status, and a scheduled workflow drains the queue at a controlled pace, marks each job done, and leaves failed jobs for the next run. Self hosted n8n also offers a queue execution mode with separate workers. That is about scaling the instance rather than controlling jobs, and it needs its own setup.
- Retry in the node
- Short blips on reads, and on writes that are safe to repeat. Fixed wait, few tries, stop on error.
- Backoff loop
- Rate limited writes where the service tells you to wait. Honor the header, grow the wait, cap the attempts.
- Error output branch
- Any side effect. Handle the failure explicitly with the failed items in hand.
- Queue and drain
- Long outages, daily limits, ordered work, or volume beyond what one execution should hold.
- Manual review
- Unknown outcomes on actions that must not repeat. Hold them and let a person or a reconciliation job decide.
Questions.
How does retry on fail work in n8n?
Enable it in the node’s Settings tab, set the number of tries and the wait between them in milliseconds, and the node reruns with the same items until it succeeds or the limit is reached. It does not inspect the status code.
How do I handle a 429 rate limit response in n8n?
Slow the sending pace first with Batching or with Loop Over Items and a Wait node. Then route the error output to a backoff loop that honors the Retry-After header when present.
Is it safe to enable retries on a node that creates records?
Only when the first attempt is known not to have taken effect or the provider safely deduplicates that operation. A lookup alone cannot prevent concurrent duplicates. Coordinate workers atomically and hold uncertain outcomes for reconciliation.
When should I queue instead of retry?
When the outage is long, the limit is daily rather than per second, the work must run in order, or the volume is more than one execution should hold.
Written by Younes Nadif · 7 September 2026 · Updated 14 September 2026