Turning on Retry On Fail in n8n feels like a fix. It waits a fixed time and tries again. But a rate-limited API often tells you how long to wait, and a blind retry can also repeat work you did not mean to repeat.
I built a small offline lab to check what a safer retry policy should do. The HTTP responses in it are simulated, so this is a test of the decision logic, not of a live API. It ran in n8n Cloud 2.43.0 with a fixed clock, and all 18 policy checks passed.
The policy in one paragraph
Four attempts in total, including the first. Only HTTP 429 is retried. A request is retried only if the job is marked safe to repeat. Everything else stops, goes to review, or is deferred.
Six cases that matter
| Case | What the policy does |
|---|---|
Retry-After: 30 (seconds) |
Waits the stated time plus a small random extra of up to 1 second, rounded up. |
Retry-After as an HTTP date |
Works out the wait from the date. It does not trust your machine clock blindly. |
| Date already in the past | Still pauses at least 1 second instead of retrying instantly. |
| Header missing, negative, fractional or garbled | Falls back to exponential backoff starting at 2 seconds, capped at 60. |
| Provider asks for a very long wait | Defers the job instead of holding the execution open. The default limit is 300 seconds. |
| A write that is not safe to repeat | Sends it to review. It is never retried automatically. |
Two rules sit behind the table. A valid wait from the provider is never shortened by your own cap. And the jitter only adds time, so it can never make you retry sooner than the API asked.
Why not just use Retry On Fail?
Fixed waits ignore what the API told you. If you also build your own loop, turn the built-in retry off, or the two multiply your attempts.
What this does not prove
- It was not tested against a live API.
- It protects one job. Shared quotas across many executions need shared coordination.
- Deferred jobs need somewhere durable to wait. The lab does not include a dispatcher.
- A "safe to retry" flag does not make a request idempotent. You still have to design for that.
Try it
The workflow JSON, fixtures and test notes are free and need no signup: n8n rate limit and Retry-After lab. I wrote up the full walkthrough there.
If your retries behave differently from what the lab expects, I would like to hear which case broke.
Top comments (0)