429 Too Many Requests — what it means and how to fix it
429 is a rate limit doing its job: the server counted more requests from you (or your app, or everyone sharing your address) than it allows in a window. It’s a “slow down”, not a “go away” — the same request usually succeeds after the window resets.
The fix, in order
- Wait, then retry once. Many limits reset in 30–60 seconds; hammering retry resets nothing and can extend the block.
- If your code got the 429, honour the Retry-After header when present, and implement exponential backoff (wait 1s, 2s, 4s…) with jitter instead of a fixed frantic loop.
- Reduce the request rate at the source: cache responses, batch lookups, stop polling every second, and check for a retry bug — code that retries instantly on failure creates its own 429 storm.
- Shared addresses share limits. An office, school, or VPN exit node puts hundreds of people behind one IP — someone else’s traffic can spend your allowance. Switching network is a fair test.
- Owners: return 429 with Retry-After, and log who’s triggering it — separating abusive bots from genuine users tells you whether to raise limits, add caching, or block.
If it still happens
If a single normal page view gets a 429, the site is probably limiting by IP and your address is flagged from earlier traffic — try another network, and if it persists, the site owner needs to know; it’s their setting, not your fault.
Common questions
How long does a 429 last? As long as the server’s window — seconds to hours. The Retry-After header, when sent, states it exactly.
Is 429 a server error or my fault? It’s a client-class code (4xx) because the request rate is the issue — but on shared IPs the “client” may be hundreds of people, not just you.
Related errors