Writing

429 Too Many Requests

Published 22 September 2026

Of all the errors in this series, HTTP 429 is the one where the answer is genuinely you. You reached the server, it understood you perfectly, and it is asking you to slow down. The useful question is not whose fault it is: it is which counter you tripped, and what resets it.

What it proves

The server is healthy and working exactly as designed. A 429 is not a failure: it is a service protecting itself, which is better behaviour than accepting work it cannot complete and timing out instead.

It also proves the network is fine. You got a status code, so the name resolved, a connection opened, your request arrived and a reply came back. Nothing here is worth escalating to a network team.

Rate limit or quota? They are not the same

Both return 429 and the difference decides what you do next.

This is the distinction that wastes the most time. A script that backs off politely and retries for an hour against a monthly quota is doing nothing but generating more 429s. Read the body: providers usually say which one you hit, even when the code cannot.

The header that answers the question

Retry-After: 30                               # seconds
Retry-After: Wed, 23 Sep 2026 00:00:00 GMT    # a date

If Retry-After is present, that is the answer and you should honour it exactly. Retrying sooner is how a rate limit becomes a ban.

Many APIs also send their own counters, and these are more useful than the status code:

• X-RateLimit-Limit: what you are allowed
• X-RateLimit-Remaining: what is left
• X-RateLimit-Reset: when the window rolls, usually a Unix timestamp

Watching Remaining and slowing down before it reaches zero is the difference between a client that works and one that is permanently half-blocked.

Who is actually being counted

"Too many requests" implies you sent them. Often you did not. The counter is keyed on something, and it is worth knowing what:

The IP row is the one that surprises people. If a limit is per-IP and your whole office leaves through one address, a colleague's script can rate-limit you while you have sent almost nothing. The tell is that it happens on a schedule you do not control, or clears when you move to another network.

A 429 in a browser usually is not you

Rate limits are an API problem. Seeing 429 while simply loading a page in a browser usually means bot protection decided you were automated: a WAF, a scraping defence, or a shared address with a bad reputation. Browsing more slowly will not help. The fix is to look like a person, or to ask the site to stop blocking your address range.

Backing off properly

The instinct (retry immediately, then keep retrying) is the one behaviour guaranteed to make it worse. Every client doing that against a service under load produces a retry storm, and the service stays down longer than the original problem warranted.

• Honour Retry-After first. Everything else is guessing when the server has told you.
• Exponential backoff. Double the wait each time (one second, two, four, eight), with a ceiling.
• Add jitter. Randomise each delay. Without it, every client that started together retries together, and you have rebuilt the stampede with extra steps.
• Cap the attempts. Then fail loudly. A job that silently retries for six hours is worse than one that stops and says why.

If you are the one returning 429

• Send Retry-After. It costs nothing and it is the difference between clients that back off and clients that hammer.
• Use 429, not 503. Some platforms shed traffic with a 503, which is technically wrong and tells the caller nothing about whether waiting will help.
• Say which limit was hit in the body. Rate or quota, and when it resets.
• Do not rate-limit on IP alone if you can key on anything better. One shared office address should not be one user.

Where 429 sits among the rest