2026-07-21 · 6 min read · Rahul Chitturi
- api
- rate-limit
- debugging
HTTP 429 means the server is asking a client to slow down, but the hard part is proving which caller, schedule, or retry policy is creating the pressure. A single missing delay can turn a temporary rate limit into a self-amplifying retry storm.
The Retry-After header may arrive as seconds or as an HTTP date. If clients, workers, and dashboards interpret that value differently, the incident can look random even when every component is following its own local rule.
Normalize the timing evidence
Collect the response headers, client retry logs, queue timestamps, and scheduler configuration before tuning limits. Put each timestamp in one timezone and one unit so the sequence of events is visible.
- Convert Retry-After dates and epoch log values to the same UTC timeline
- Check whether clients use fixed delay, exponential backoff, jitter, or immediate retry
- Look for cron jobs or batch workers that all resume at the same minute
- Compare staging and production rate-limit settings before changing code
Separate rate limits from payload bugs
A 429 can hide a second issue. If retry requests carry malformed JSON, stale tokens, or unexpected pagination parameters, the server may reject work repeatedly after the backoff window opens.
Use sanitized request examples when sharing notes. Preserve headers, method, path, and payload shape, but remove customer identifiers and secrets before diffing examples with teammates.
A Flashman workflow
Use the timestamp converter to align Retry-After values with log lines, the JSON formatter to inspect safe request fixtures, the diff tool to compare client settings, and the cron helper when scheduled jobs are part of the burst.
A good fix names the exact source of pressure: no jitter, seconds-vs-date parsing, shared resume time, worker fan-out, or an upstream limit that is lower than the client assumes.