429 Too Many Requests — What It Means and How to Fix It

What 429 means

Rate limiting. The server is deliberately refusing traffic to protect itself. A well-behaved 429 includes a Retry-After header telling you how long to wait — and clients that ignore it turn a brief throttle into a sustained outage.

Common causes

•Genuinely exceeding a documented API rate limit.
•A retry loop with no backoff amplifying an initial failure.
•A shared NAT or office IP hitting a per-IP limit collectively.
•A monitoring or scraping tool polling far too aggressively.
•A misconfigured limit that is simply too low for real traffic.

How to fix it

Honour Retry-After. Add exponential backoff with jitter to every retry path — synchronised retries from many clients are what turn a transient limit into a thundering herd. If limits are per-IP and you are behind shared egress, you may need per-key limiting instead.

Catching 429 before your users report it

If your own monitoring triggers 429s, lengthen the check interval or allowlist the probes. A monitor that causes the outage it is watching for is worse than no monitor.

Monitor for 429 responses free

Often confused with

503 Service Unavailable 403 Forbidden

← All HTTP status codes

429 Too Many Requests — questions

How long should I wait after a 429?

Exactly as long as the Retry-After header says. If the response omits it, back off exponentially — one second, then two, then four — with a little random jitter so every client does not retry in lockstep.

Can rate limiting cause an outage?

Yes, and it is a common cascading failure. A brief limit triggers retries, the retries increase load, and the limit tightens. Backoff with jitter is what breaks that loop.

429