HTTP Request in n8n: retry, timeout and reliable API calls

A workflow that runs perfectly in testing, then fails every other night in production: in the vast majority of cases, the culprit is an API call that failed transiently — a latency spike, a passing 503, a rate limit hit — and an HTTP Request node left on its default settings, meaning no retry and no properly sized timeout. The good news is that n8n ships with everything needed to absorb these failures without stopping the workflow. You just need to know which options to enable, and above all which errors to retry or not.

Why API calls fail even when everything is configured correctly

A failed HTTP call isn't necessarily the sign of a bug. Three families of transient failures are unavoidable as soon as you depend on a remote service:

• The network: packet loss, a momentary DNS blip, a reset connection. Rare at the scale of one request, statistically certain at the scale of thousands of executions.
• The remote server: a 500 or a 503 during a deployment, a saturated database, a third-party service mid-incident. There's nothing you can do about it, but ten seconds later everything works again.
• Tail latency: the request succeeds, but takes thirty seconds instead of three hundred milliseconds, because it landed on a momentarily overloaded server.

That last point is the most counter-intuitive. A Google study published in Communications of the ACM (Dean & Barroso, 2013, "The Tail at Scale" — Google Scholar) shows that tail latency is a structural property of distributed systems: even when every component is fast on average, a small fraction of requests suffers extreme delays, and that fraction mechanically grows with the number of services involved. The authors argue for techniques that tolerate this variability — tuned timeouts, hedged requests — rather than hoping to eliminate it. Translated for n8n: explicitly sizing the timeout and retries of every critical call isn't paranoia, it's the normal response to normal API behavior.

Retry On Fail: the setting to know in the node's settings

Retry isn't configured in the visible parameters of the HTTP Request node, but in its Settings tab (common to most n8n nodes):

• Retry On Fail: enables automatic retries when the node fails.
• Max Tries: the total number of attempts before the node is considered definitively failed.
• Wait Between Tries: the delay, in milliseconds, between two attempts.

With Retry On Fail enabled and a Wait Between Tries of a few seconds, a passing 503 or a network micro-outage becomes invisible: the node retries, succeeds, and the workflow carries on as if nothing happened. This is the setting that, on its own, eliminates most unexplained overnight failures.

Two limitations to keep in mind:

• The delay between attempts is fixed: n8n doesn't do native exponential backoff at this level. For more sophisticated retry patterns (wait 2 s, then 10 s, then 60 s), you have to build a loop with a Wait node — mostly useful against rate limits, as detailed in our article on 429 errors from AI APIs.
• A retry reruns the entire node: if it processes several items or several pages of an API (see our guide to pagination with HTTP Request), think through what a full rerun implies.

The timeout: stop waiting at the right moment

The HTTP Request node offers a Timeout option (in the node's Options) that caps how long it waits for a response. Without a properly sized timeout, a dragging request blocks the execution for long minutes — and on a busy instance, several blocked executions eventually saturate the queue, a topic that connects to moving to queue mode with Redis.

The right reflex: measure the normal latency of the API you're calling (a few executions are enough), then set the timeout well above the common case but well below infinity — say 10 to 30 seconds for a typical API, more for a long LLM generation. Combined with Retry On Fail, a short timeout turns a request that landed on a slow server into a simple new attempt — exactly the logic Dean and Barroso recommend: better to retry quickly than to wait indefinitely for a response that may never come.

Errors to retry, errors to let fail

The entire subtlety of a retry strategy lies in this distinction:

• Retry — transient failures: 429 (rate limit: retrying after a pause makes sense), 5xx (server-side error, often temporary), timeouts and network errors. A new attempt has a real probability of success.
• Do NOT retry — deterministic failures: 400 (your request is malformed: it will stay malformed), 401 (invalid or expired credential), 404 (the resource doesn't exist). Retrying a 401 five times only delays the alert and burns quota.

In practice in n8n: enable Retry On Fail to absorb the transients, but follow the node with logic that inspects the error code once all attempts have failed — an IF on the status code that routes 4xx to an immediate notification ("fix your request or your credential") and persistent 5xx to a deferred retry queue.

Backoff, or why retrying immediately makes things worse

If an API returns 429 or 503 because it's saturated, retrying it immediately — from ten parallel executions at once — adds load to a service that's already struggling. It's the classic mechanism of self-sustaining congestion: every client that insists slows down recovery for everyone. Hence two simple rules:

• Never set Wait Between Tries to a near-zero value: a few seconds at minimum.
• Faced with a recurring rate limit, reduce the upstream cadence (batching, a Wait node between items) rather than stacking retries — which also has a direct effect on the bill when the API is paid, as covered in our guide to tracking the cost of AI calls.

Idempotency: the hidden risk of retrying a POST

A GET can be replayed without consequence. A POST cannot: if the server processed the request but the response was lost (timeout, network cut at the wrong moment), the retry creates a duplicate — a second order, a second ticket, a second email sent. Before enabling Retry On Fail on a node that writes, ask three questions:

• Does the API accept an idempotency key (a unique identifier per operation, which the server uses to deduplicate)? If so, send it systematically.
• Can you deduplicate on the n8n side, by checking whether the resource exists before creating it?
• Is a duplicate acceptable for this use case (a duplicate Slack notification is annoying; a duplicate payment is not)?

These mechanisms are exactly the same as for inbound webhooks, detailed in our article on idempotency and duplicate prevention.

Continue On Fail and error branches: route the failure instead of stopping everything

By default, a failed node (after retries are exhausted) stops the entire execution. The node's settings let you change this behavior: instead of stopping the workflow, the node can continue and pass the error along — either through the normal flow, or via a dedicated error output that appears as a second branch on the node.

That error branch is invaluable whenever a workflow processes a batch of items: one failing item out of fifty must not doom the other forty-nine. The typical pattern: the main branch keeps processing the successful items, while the error branch records the failures (in a database, a Google Sheet, a retry queue) and notifies the team. It's the pattern our RAG question-answering API workflow uses to return a clean response to the caller even when an internal call fails.

The global Error Workflow: the final safety net

Retry, timeout and error branches handle anticipated failures. For everything else — the node nobody thought about, the execution that crashes on an uncovered case — n8n lets you attach an Error Workflow to each workflow: a separate workflow, triggered automatically when an execution fails, that receives the error context (which workflow, which node, what message).

The right architecture: a single global Error Workflow for the whole instance, notifying Slack or email with the workflow name and a link to the failed execution, referenced in the settings of every production workflow. Its full setup is covered in our Error Workflow guide — it's the essential complement to node-level settings, not their replacement.

Pre-production checklist

• Retry On Fail enabled on every critical HTTP Request, with a Wait Between Tries of a few seconds.
• Explicit timeout, calibrated on the API's real latency (neither 5 seconds for an LLM, nor 5 minutes for a CRM).
• 4xx routed to an alert, not to a retry: a 401 gets fixed, not retried.
• Idempotency verified before any retry on a POST.
• Error branch on batch processing, global Error Workflow for everything else.

These settings take ten minutes per workflow and radically change production behavior: transient incidents absorb themselves, real errors surface immediately with their context. The workflows in the FlowKit packs — including the Inbox AI Pack (€79), which chains calls to email and AI APIs — ship with these settings already in place; all that's left is tuning the thresholds to your APIs.