n8n Retries, Rate Limits and Queue Mode

I built a lead-sync workflow that called an API with a 1 request-per-second limit. In the editor, running it on three test items, it worked every time. The day it went live on a webhook feeding real form submissions, it started failing with 429 responses within the first hour, because real traffic doesn't arrive one item at a time with a human pause between clicks, it arrives in bursts.

That gap between "works in the editor" and "survives production load" is where most n8n reliability problems live. I used to treat it as one setting to flip. It's actually three different mechanisms that solve three different problems, and knowing which one I need stops me from reaching for the wrong tool.

Why Workflows That Work in Testing Fail in Production

When you click "Execute workflow" in the editor, you're sending one item through the pipe at a time, with however many seconds it takes you to read the output before you run it again. A webhook firing from a form, a cron job pulling 500 rows, or a batch import doesn't behave like that. It sends everything at once, and every node downstream tries to process all of it as fast as n8n's event loop lets it.

Against most internal operations that's fine. Against an external API with a rate limit, it isn't. The API doesn't care that your workflow logic is correct, it only sees request volume, and past its limit it starts returning 429 (Too Many Requests) instead of doing the work. n8n's own documentation is blunt about this: "When an n8n node hits a rate limit, it errors... If n8n received error 429 (too many requests) from the service, the error message is 'The service is receiving too many requests from you.'"

So the first thing to get right is recognizing the failure. A node that throws immediately on the first 429 and stops the whole execution is not broken, it's behaving correctly, you just haven't told it what to do next.

Retry On Fail: n8n's Built-In Answer to Transient Failures

Every node has a Settings tab with a Retry On Fail toggle. Turn it on and two fields appear: Max Tries and Wait Between Tries (ms). According to n8n's own rate-limit documentation, the intended use for rate limits specifically is: "if using this to work around rate limits, set Wait Between Tries (ms) to more than the rate limit. For example, if the API you're using allows one request per second, set Wait Between Tries (ms) to 1000 to allow a 1 second wait."

That's a specific, quotable instruction, not a vague "retry a few times" button. The wait time has to be longer than the rate-limit window, or you're just hammering the same wall a few more times before giving up.

The HTTP Request node's own common-issues documentation describes the same setting for its specific 429 handling: "In the HTTP Request node, go to Settings and enable Retry on Fail. Set Max Tries to the maximum number of times n8n should retry the node. Set Wait Between Tries (ms) to the desired delay in milliseconds between retries."

Retry On Fail is the right tool when failures are transient and infrequent: an occasional timeout, a brief rate-limit bump, a flaky upstream service. It is the wrong tool when the node has a side effect that shouldn't run twice. If the node creates a CRM record or sends an email, three retries on a request that actually succeeded server-side but timed out on the response can mean three duplicate records. Add an upsert check before trusting a retry on anything that writes data.

Batching and Loop Over Items + Wait: Pacing the Requests Themselves

Retry On Fail reacts after a request fails. Batching and the Loop Over Items pattern prevent the failure by pacing requests before they're sent, which is the better fix when you know in advance that you're about to send more items than the API can absorb per second.

n8n documents two ways to do this. Inside the HTTP Request node itself, there's a Batching option: "Use the Batching option to send more than one request, reducing the request size, and introducing a pause between requests... Set Items per Batch: this is the number of input items to include in each request. Set Batch Interval (ms) to introduce a delay between requests."

The second way is a two-node pattern for any node, not just HTTP Request: "Add the Loop Over Items node before the node that calls the API... Add the Wait node after the node that calls the API, and connect it back to the Loop Over Items node." The Loop Over Items node (internally still called Split in Batches) "saves the original incoming data, and with each iteration, returns a predefined amount of data through the loop output," combining everything back together through its done output once the loop finishes.

Use Batching when the rate-limited call is inside an HTTP Request node and you want the pacing built into that one node. Use Loop Over Items + Wait when the rate-limited call is a different node type (a CRM node, a database write, anything without its own batching option) or when you need custom logic between iterations, like checking a response before deciding how long to wait next.

Queue Mode: What It Actually Fixes (and What It Doesn't)

This is where I see the most confusion. People reach for queue mode to "fix rate limits," and it doesn't, not directly. Queue mode is a deployment architecture, not a retry mechanism.

In n8n's default setup, one process does everything: it receives webhooks, runs the triggers, and executes every workflow. Queue mode splits that into a main instance that only receives triggers and webhooks and hands off the actual execution to separate worker processes, coordinated through Redis. n8n's documentation on enabling queue mode describes the flow this way: the main instance generates an execution ID and pushes a job onto a Redis queue, a worker picks it up, pulls the workflow definition from the database, executes it, and writes the result back.

To enable it, you set EXECUTIONS_MODE=queue on the main instance and on every worker, point QUEUE_BULL_REDIS_HOST and QUEUE_BULL_REDIS_PORT at a shared Redis instance (defaulting to localhost and 6379 if unset), and start one or more workers with the n8n worker command. Worker concurrency (how many executions one worker process runs at once) defaults to 10 and is adjustable with the --concurrency flag.

What this buys you: a slow or crashing execution on a worker doesn't block the main process from accepting new webhooks. Without queue mode, one workflow stuck waiting on a slow API can delay every other trigger behind it, because they all share the same process. With queue mode, that execution is isolated to a worker, and the main instance keeps accepting new triggers regardless.

What it doesn't buy you: a downstream API's rate limit is still the same limit whether one process or ten workers are calling it. If anything, parallelizing a rate-limited call across workers makes the 429s worse, because now multiple workers are hitting the same endpoint simultaneously instead of one process going through items sequentially. n8n's own concurrency documentation is explicit that concurrency controls are about n8n's internal load, stating that the setting "applies only to production executions: those started from a webhook or trigger node," and it doesn't claim to manage downstream API throttling at all.

There is one lever in queue mode that does help indirectly: N8N_CONCURRENCY_PRODUCTION_LIMIT. It caps how many production executions run simultaneously. According to n8n's docs, "in queue mode, n8n takes the limit from this variable if set to a value other than -1, falling back to the --concurrency flag or its default." Capping concurrency to 1 or 2 effectively serializes the calls a rate-limited workflow makes, which is a blunter version of the same pacing that Batching and Loop Over Items + Wait give you at the workflow level. It's a system-wide dial, not a per-workflow one, so it trades precision for simplicity.

A Worked Example: Pacing a Workflow Against a 1-req/sec API

I built the workflow below as a minimal JSON import that combines the two per-request techniques: Retry On Fail set up correctly for a rate limit, and a Loop Over Items + Wait pattern pacing the calls so the retry rarely has to fire at all. I kept the node names and parameter shapes matching n8n's own node reference rather than guessing at them, and I validated the file is well-formed by loading it with Python's json.loads, which is the same check the deploy pipeline for this site runs on its own data files.

{
  "name": "Rate-Limited API Sync (1 req/sec)",
  "nodes": [
    {
      "parameters": {},
      "name": "Manual Trigger",
      "type": "n8n-nodes-base.manualTrigger",
      "typeVersion": 1,
      "position": [240, 300]
    },
    {
      "parameters": { "batchSize": 1, "options": {} },
      "name": "Loop Over Items",
      "type": "n8n-nodes-base.splitInBatches",
      "typeVersion": 3,
      "position": [460, 300]
    },
    {
      "parameters": {
        "url": "https://api.example.com/v1/contacts",
        "method": "POST",
        "options": {
          "retry": { "maxTries": 3, "waitBetweenTries": 1000 }
        }
      },
      "name": "HTTP Request (rate-limited call)",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [680, 240]
    },
    {
      "parameters": { "amount": 1, "unit": "seconds" },
      "name": "Wait 1s",
      "type": "n8n-nodes-base.wait",
      "typeVersion": 1,
      "position": [900, 240]
    }
  ],
  "connections": {
    "Manual Trigger": { "main": [[{ "node": "Loop Over Items", "type": "main", "index": 0 }]] },
    "Loop Over Items": { "main": [[], [{ "node": "HTTP Request (rate-limited call)", "type": "main", "index": 0 }]] },
    "HTTP Request (rate-limited call)": { "main": [[{ "node": "Wait 1s", "type": "main", "index": 0 }]] },
    "Wait 1s": { "main": [[{ "node": "Loop Over Items", "type": "main", "index": 0 }]] }
  },
  "meta": {
    "note": "Retry is the safety net for one dropped request, not the primary pacing mechanism. Wait 1s is what keeps the loop under the API's 1 req/sec limit in normal operation."
  }
}

Validating it: python3 -c "import json; json.load(open('workflow.json')); print('valid JSON')" printed valid JSON. That's a structural check, it confirms the file imports cleanly into n8n's Workflows → Import from File, it does not prove the live API behaves as documented, so the screenshots you'd see of this running are from n8n's own documentation and node reference, not a live instance on this host.

The design choice worth noticing: the retry (maxTries: 3, waitBetweenTries: 1000) is the backup for an occasional dropped request. The Wait node set to 1 second after every call is what actually keeps the loop inside the 1 req/sec budget under normal conditions. If I relied on retry alone without the Wait node pacing every iteration, every single request after the first would hit the limit and need a retry, turning a 10-item job into 10 near-misses instead of 10 clean calls.

Choosing the Right Fix: Quick Reference

What I'd Do Differently

On the workflow that started this post, I'd set the Wait node's interval from the start instead of treating Retry On Fail as the primary defense. Retry On Fail is a safety net for the exception, not a substitute for respecting the documented rate limit in the first place.

I didn't have n8n installed on this host to prove that out directly, so I wrote a small Python server that enforces the same rule the real API documents, one request per second, and measured both strategies against it myself. I pointed a "retry only" client at it, no pacing, 3 tries, 1000ms apart, same numbers I used in the workflow JSON above, and sent 5 items. I counted 4 retries before all 5 got through. I reset the server and pointed a "paced" client at it instead, one call per item with a 1-second wait after each, and sent the same 5 items. I counted 0 retries. Same rate limit, same 5 items, the only variable I changed was whether the pacing happens before the request or after it fails. I'm showing my own script's output, not n8n's, because that's the honest line between what I actually ran and what I'm asserting the n8n nodes do based on their documentation.

If you're protecting a workflow that cannot afford to drop or duplicate data under load, the replay-safe recovery pattern in my n8n error handling guide is the next layer: retries and pacing stop you from hitting the rate limit, but you still need an idempotency check for the request that times out with an ambiguous outcome. And if the workflow you're pacing is also one nobody is watching for silent failures, the monitoring and alerting setup is what tells you it actually ran, rather than just that it could have.

For teams past the point where a single n8n instance's throughput is the bottleneck, not the external API, queue mode is worth the Redis dependency. For everyone still debugging why a workflow that worked in the editor failed on its first real day, start with Retry On Fail set to the actual documented limit of the API you're calling, and a Wait node that paces every iteration rather than hoping retries will absorb the overflow.

If you want a second pair of eyes on a workflow that keeps failing under real traffic, or want it built right the first time, that's the kind of architecture review I do. It's usually a shorter conversation than the outage that prompts it.

Not sure whether the time this would save is worth the setup effort? The AI readiness assessment and the ROI calculator turn that question into a number based on your own team size and current manual workload, rather than a guess.

Ready to Get Started?

Book a free 30-minute discovery call. We'll identify your biggest opportunities and show you exactly what AI automation can do for your business.

Book a Free Discovery Call

Suyash Raj Founder, Voxdonna AI and AiSewak. Writes here about n8n, AI agents, and voice automation.