Rate-Limit-Proof n8n AI Workflows: Queues, Retries, Backoff

Your Loop Over Items fans 200 rows straight into an LLM node, and somewhere around row 40 the whole run turns red with "429 Too Many Requests." Every guide online hands you a different fix, and none says when each one is enough. The honest answer to an n8n rate limit is a ladder: node retry, batching, Wait, hand-rolled backoff, then a queue.

Why do n8n AI workflows hit 429, and what is the rate limit really?#

An n8n rate limit error (HTTP 429, "Too Many Requests") fires when you send requests faster than the provider allows, easy to do when a Loop Over Items node fans dozens of rows into an LLM call. Providers cap two dimensions: requests per minute and tokens per minute. Long prompts blow the token budget even at a low request count.

A 429 is a signal, not a wall. Most APIs return a Retry-After header telling you exactly how long to wait, and the server knows its own window better than any client-side guess you invent. Honoring that header first is the polite and effective move, and it is where every honest strategy starts before it reaches for cleverness.

Climb the ladder only as far as the workload needs. Most jobs stop at batching or Loop plus Wait.

The practical upshot: you rarely need the heaviest tool. Sizing every fix below starts with your provider's published RPM and TPM limits, which are plan-specific and change often, so treat them as the input, not something to hard-code. Verify them on the provider's own page before you tune a single interval.

What are the two built-in ways n8n handles rate limits?#

n8n documents two built-in approaches: the per-node Retry On Fail setting and the Loop Over Items plus Wait combination (n8n docs). Retry On Fail is a toggle where you set Max Tries and Wait Between Tries in milliseconds; for rate limits you push that wait above the provider's window.

The catch, stated plainly, is that the built-in retry caps at 5 tries and a 5-second wait, so it rides out the odd blip but not a sustained throttle. Loop Over Items (technical name Split In Batches) breaks input into chunks, and a Wait node placed after the call and looped back paces those chunks: batch size 1 processes one item per iteration, higher sizes process several.

The toggle is great for the odd blip; serious backoff needs the Code node because the toggle caps at 5 tries and 5 seconds.

HTTP Request Batching is the same idea inside a single node. Under Add Option, Batching exposes "Items per Batch" (how many input items per request) and "Batch Interval (ms)" (the delay between requests). Set the interval to 1000 for roughly one request per second. The docs describe this as the equivalent of Loop Over Items plus Wait, so choose whichever reads cleaner in your flow.

Honor the server's Retry-After first; fall back to exponential backoff with jitter only when there is no header.

Here is the quick map from a symptom to the mechanism that fits it.

How do you add real exponential backoff and respect Retry-After?#

When the built-in retry runs out of room, move the logic into a Code node. Five tries and a 5-second ceiling cannot ride out a multi-second or escalating throttle, and the toggle ignores Retry-After entirely. On a 429 you want a delay that grows with each attempt, not a flat wait that keeps slamming a closed door.

The pattern is reproducible. Compute the delay as Math.pow(2, retryCount) * 1000 milliseconds so it doubles each attempt, add random jitter so parallel items do not retry in lockstep (the thundering-herd problem), and cap the retry count yourself. Use setTimeout for the dynamic wait, since a fixed Wait node cannot vary its delay from a response (n8n docs).

Start from the failure shape; every path ends at a workflow that runs within the limit.

Honor Retry-After before your own math. If the 429 response carries that header, wait exactly the value it gives, because the server is telling you its real window; fall back to 2^n plus jitter only when the header is absent. Wrap the provider call so this logic sits around it, and send exhausted retries to an error branch that a separate workflow can alert on, which the n8n error handling guide walks through in full.

How do you queue requests so you never trip the limit?#

The architecture shift is to stop rate-limiting inside a loop and instead separate the producer, which generates the work items, from the consumer, which executes them at a controlled pace. n8n's docs recommend exactly this at scale: a queue that holds work rather than immediate retries that keep colliding with the ceiling you already hit.

In practice the producer writes items to a store (a database table, an n8n data table, Redis, or a queue), and a scheduled consumer workflow pulls a fixed number per run and processes them. That turns a burst into a steady drip. You pace the consumer with the same tools as before: a Schedule Trigger cadence plus HTTP batching or Loop plus Wait, sized to stay under the provider's RPM and TPM.

Reach for the instance-level lever too. N8N_CONCURRENCY_PRODUCTION_LIMIT caps concurrent production executions with a FIFO queue for the excess (default off at -1), limiting how many trigger-started runs hit a downstream API at once, though it excludes manual and sub-workflow executions (n8n docs). Pair the queue with multi-model fallback so an overloaded primary model degrades to a backup instead of failing outright.

Which rate-limit pattern should you use?#

Match the tool to the failure shape rather than reaching for a queue when batching would do. An occasional blip wants Retry On Fail. A steady per-second cap wants HTTP batching sized to that limit. Spiky bursts want Code-node backoff with jitter and Retry-After. A hard quota at scale wants a producer-consumer queue.

Climb the ladder only as far as your workload forces you. Most jobs stop at batching or Loop plus Wait, and reaching for a queue on a workflow that a 1000-millisecond interval would have fixed just adds a store and a second workflow to maintain. Size every rung from your provider's published limits, verify those numbers on the vendor's page this week, and let the failure shape, not a hype ranking, pick the pattern.