429 Too Many Requests — Causes and How to Fix It

Who is doing the limiting?

Identify the source before changing anything. The response itself usually tells you if you look at the headers rather than the page.

Retry-After: the header that tells you what to do

A well-behaved 429 includes a Retry-After header, and it is the single most useful piece of information in the response.

It comes in two forms: a number of seconds to wait, or an HTTP date to wait until. Either way it is the server telling you exactly when it will start accepting requests again — which is far better than guessing.

If you are writing a client, read it and honour it. Retrying immediately after a 429 is the behaviour that gets IP addresses blocked outright rather than merely throttled, because from the server side it is indistinguishable from an attack.

If you are issuing 429s, send it. Without Retry-After, well-written clients have to guess, and badly written ones will hammer you continuously.

Common causes, most frequent first

• Your code calls an API in a loop without pacing. Iterating over a few thousand records with one API call each will hit almost any rate limit within seconds.
• No caching on repeated calls. Fetching the same exchange rate or product data on every page load multiplies your request count by your traffic.
• Bot protection triggering on legitimate traffic. Cloudflare and similar tools sometimes classify a monitoring tool, a feed reader or an aggressive but honest crawler as abuse.
• Shared IP address. On shared hosting or behind corporate NAT, you inherit the reputation and the request count of everyone else using that address.
• wp-cron or similar polling on a busy site. WordPress fires cron on page views; on a high-traffic site that can mean hundreds of internal requests a minute.
• A retry loop with no backoff. The first 429 triggers a retry, which triggers another 429, which triggers another retry — this turns a brief limit into a sustained block.
• Login or form endpoints being brute-forced. Here the 429 is doing its job and the right response is to leave it alone.

If your code is being limited: back off properly

When you are the client, the correct behaviour is well established and worth implementing once, properly.

Use exponential backoff with jitter. Wait one second, then two, then four, then eight — and add a small random amount to each. The randomness matters: without it, every client that failed at the same moment retries at the same moment, producing a synchronised wave that keeps everyone limited.

Honour Retry-After when it is present. It overrides your own backoff calculation, because the server knows better than your algorithm does.

Cap the number of retries. Infinite retry loops turn a temporary limit into a permanent block and hide the underlying problem from you.

Cache aggressively. The cheapest request is the one you never make. Data that changes hourly does not need fetching on every page view, and a short cache often removes the rate-limit problem entirely.

Batch where the API supports it. One request for a hundred records beats a hundred requests for one record, and most APIs count requests rather than records.

If your visitors are getting 429

• Check whether it is your server or your CDN. The error page tells you: a branded page with a ray ID is the CDN, a plain one is your server.
• Review the actual request pattern in the access log before loosening anything. If the traffic really is abusive, the limit is working and should stay.
• Look for false positives on good bots. Googlebot, uptime monitors and legitimate feed readers can trip aggressive rules — and rate-limiting Googlebot will cost you rankings.
• Check your own site is not generating the load. Plugins that poll internal endpoints, or a misconfigured cron, can consume the entire limit before real visitors arrive.
• Enable page caching before raising limits. Cached pages never reach the rate limiter at all, which fixes the cause rather than the symptom.
• Set limits per endpoint rather than globally. Login and API endpoints deserve tight limits; static pages usually do not need any.

Why raising the limit is usually the wrong first move

The instinct when seeing 429 is to raise the threshold. Occasionally that is right, but more often it converts one problem into a worse one.

Rate limits exist to protect finite capacity. Raising them without adding capacity means the requests now reach your application, consume workers and memory, and you trade a clean 429 for a slow site or a 503 — a worse experience delivered more expensively.

The better sequence is: cache first, so most requests never reach the limiter; fix whatever is generating unnecessary load; then, if genuine demand still exceeds the limit, raise it and add the capacity to serve it.

The exception is a limit that was simply set too low for normal traffic. If your access log shows ordinary visitors browsing normally and hitting limits, that is a misconfiguration and raising it is the correct fix.