n8n Retry Failed Node

A momentary API blip, a five-second network hiccup, a brief rate limit, should not take down an entire workflow. Most of the time it does not need to, because n8n has retry logic built directly into almost every node. The catch is that this built-in retry has a specific configuration trap that silently disables it, and it is easy to have retry looking enabled in the settings panel while it never actually fires. This post covers how the built-in retry works, that trap specifically, and when it is worth building a custom retry loop instead.

Why API Calls Fail

Most API failures a workflow encounters are transient rather than permanent: a momentary network issue, a brief server-side hiccup, or a rate limit that resolves itself within seconds. These do not need a human to intervene, they need the request tried again after a short pause. A smaller share of failures are genuinely permanent, bad credentials, a malformed request, a resource that does not exist, and no amount of retrying fixes those. Distinguishing between the two matters, because retrying a permanent failure just burns time and API calls without ever succeeding.

Built-In Retry Settings

Nearly every node in n8n, from a simple HTTP Request to an AI Agent, has a Retry On Fail toggle in its Settings tab. Turn it on, set Max Tries (how many total attempts before giving up) and Wait Between Tries in milliseconds (the pause between each attempt), and n8n handles the retry automatically without any additional nodes or logic. For most transient API failures, three to five tries with a delay of a few seconds is a reasonable starting point.

There is a hard ceiling worth knowing about on the built-in settings: the UI caps Max Tries at 5 and Wait Between Tries at 5000 milliseconds, silently resetting anything higher back to those limits. If your use case genuinely needs more retries or a longer delay between them than that, the built-in toggle cannot express it, and you need a custom loop instead.

Retry With Wait

The mechanism itself is simple: on failure, n8n pauses for the configured wait time, then attempts the node again, up to the configured maximum tries, before finally treating it as a failure and moving to whatever error handling, or lack of it, follows. This all happens within the single node execution, with no extra nodes needed in the workflow canvas to express it.

Here is the trap, and it catches nearly everyone the first time they combine retry with error output handling: if Retry On Fail is enabled but the node's On Error setting is set to Continue or Continue (using error output) rather than Stop Workflow, the retry settings are silently ignored entirely. A single failure moves straight to the error path with no retry attempt at all, even though the settings panel still shows Retry On Fail turned on. If you have built error-output branching on a node and retries do not seem to be firing, this is almost always why. Check the On Error setting alongside Retry On Fail, not just the retry toggle in isolation.

Handling HTTP 429

For rate limit errors specifically, set Wait Between Tries to something longer than the rate limit window itself, if an API allows one request per second, a 1000 millisecond wait between tries gives it room to reset before the next attempt. For handling rate limits across a batch of items rather than a single node's retries, n8n's Loop Over Items node combined with a Wait node between iterations, or the HTTP Request node's built-in batching option with a configured interval, spreads requests out proactively rather than relying purely on reactive retries after a limit is already hit.

Exponential Backoff

The built-in retry uses a fixed wait time between every attempt, which is fine for most transient failures but not ideal for a genuinely struggling API that needs increasing breathing room rather than the same short pause repeated identically. Exponential backoff, doubling the wait after each failed attempt, gives a recovering service progressively more room, and it needs to be built manually since the node-level setting does not support it. The standard pattern: a Set node tracking the current attempt count and delay, an IF node checking whether to continue, a Wait node pausing for the current delay, and a loop back to the failing node, with the delay expression doubling on each pass. n8n has published workflow templates demonstrating exactly this pattern if you want a working reference rather than building it from scratch.

Preventing Duplicate Actions

A retried request that actually succeeded server-side but the response was lost before your workflow saw it can result in the same action executing twice on a retry, a duplicate CRM record, a duplicate charge, depending on what the node does. For anything that creates or modifies real data, design the operation to be idempotent where the target system supports it, an upsert by a unique key rather than a blind create, so a retry that duplicates the request does not duplicate the underlying effect.

Error Workflow vs Retry Logic

Retry and the Error Trigger, covered in n8n Error Trigger Guide, solve different layers of the same problem. Node-level retry handles the transient failures automatically without ever needing a human to know they happened. The Error Trigger and its downstream error workflow exist for what is left after retries are genuinely exhausted, a failure that needs a person to look at it. Build both, retry for the noise, alerting for what actually matters.

Testing Retries

Configure a node to call something that will simulate one or more failures before eventually succeeding, and confirm the retry actually fires the expected number of times with the expected delay between attempts. This is also the moment to double-check the On Error setting is not silently swallowing the retry, since a retry that appears configured correctly but is never actually exercised is the kind of gap that only shows up once a real failure happens in production.

If your n8n workflows are failing on transient API errors without proper retry handling, or you need a custom exponential backoff loop for a particularly flaky integration, that is exactly the kind of reliability work I take on for clients. Book a free 30-minute call and bring your current setup, and we will get retry logic built in properly.

Frequently Asked Questions

How do I retry a failed node in n8n?

Open the node's Settings tab, enable Retry On Fail, and set Max Tries and Wait Between Tries (ms). Make sure the node's On Error setting is not set to Continue, since that silently disables retry regardless of the toggle's state.

Can n8n automatically retry API requests?

Yes, almost every node has a built-in Retry On Fail setting that automatically retries a failed request after a configured delay, up to a maximum number of attempts, with no additional nodes needed.

How do I handle 429 errors in n8n?

Set Wait Between Tries to longer than the API's rate limit window, or use Loop Over Items with a Wait node between iterations, or the HTTP Request node's batching option, to proactively space out requests rather than relying only on reactive retries.

How many times should n8n retry an API call?

The built-in setting caps at 5 tries and a 5000ms wait, a reasonable range for most transient failures. For anything needing more retries or longer delays, particularly with exponential backoff, build a custom loop instead of the node-level setting.

How do I avoid duplicate actions after retrying?

Design the operation to be idempotent where the target system supports it, using an upsert by a unique identifier rather than a blind create, so a retry that resends a request that actually already succeeded does not create a duplicate record.

Should I use Error Trigger or retry logic?

Both, for different purposes. Retry handles transient failures automatically without needing a person. The Error Trigger and its error workflow handle what remains after retries are exhausted, genuine failures that need human attention.

If you would rather have this configured than configure it yourself, I take on n8n reliability and error handling work through Fiverr.