Before You Retry a 429 in n8n: 6 Retry-After Cases I Tested

Description and use

In n8n, the built‑in retry ignores the Retry‑After header and can repeat unsafe requests. The recipe in the article handles all Retry‑After cases, adds jitter, caps long waits, and defers unsafe writes, providing safe and predictable retry logic.

Problem

Blind retry logic in n8n ignores API-provided wait times and can repeat unsafe work.

Outcome

All 18 policy checks passed in an offline lab; policy correctly handles various Retry-After scenarios and unsafe writes.

Workflow

• 1. Enable Retry On Fail in n8n.
• 2. Add a safety flag to mark requests safe to repeat.
• 3. On HTTP 429, check Retry-After header: if seconds, wait header+random up to 1s; if HTTP date, compute wait from date; if past, wait at least 1s; if missing/garbled, use exponential backoff starting 2s capped 60s.
• 4. If Retry-After exceeds 300s, defer job instead of blocking execution.
• 5. If request is not safe to repeat, send to review and do not retry automatically.
• 6. Allow maximum 4 attempts total (including first).

Evidence

Turning on Retry On Fail in n8n feels like a fix. It waits a fixed time and tries again.

Source

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.

Source

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.

Source

If your retries behave differently from what the lab expects, I would like to hear which case broke.

Source