n8n HTTP 429: wait for Retry-After instead of guessing
说明与用途
在 n8n 中,处理 HTTP 429 时应读取 Retry-After 头,降低请求速率,等待指定时间,并限制重试次数以避免重复写入。
问题
An n8n workflow that calls an API will hit HTTP 429 sooner or later, and the common fix of adding a fixed Wait node is unreliable.
结果
The custom loop correctly honors Retry-After, reduces burst, caps attempts, and avoids duplicate writes, achieving a PASS after a simulated 429 with a real wait of at least two seconds.
工作流
- Enable Include Response Headers and Status in the HTTP Request node
- Read status, body, and Retry-After header
- Reduce batch size and set a batch interval matching the provider quota
- If Retry-After present, wait that many seconds (add jitter on top, never subtract)
- If missing or invalid, use bounded backoff (2,4,8s capped at 60s)
- Keep job ID and count attempts; stop or defer if wait exceeds 300s
- Retry writes only when an idempotency key or duplicate check is available
证据
Inspect the 429 response, slow the request rate, and honor a valid Retry-After header before retrying.
A 429 can mean a per-second burst, a daily cap or a token limit, and the right fix differs.
If the header is missing or invalid, fall back to a bounded backoff (the lab uses 2, 4 and 8 seconds, capped at 60).
Keep the job ID through the whole loop, count total attempts (four attempts means four in total, including the first), and stop or defer when the wait is too long.
- 记录日期: 2026-11-01T10:44:00.771Z