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

A 429 Too Many Requests is a speed limit, not a crash. Something between the client and the content — the application, an API gateway, a WAF, or a CDN — counted requests from one source, decided the source had asked too often in too short a time, and told it to slow down.

Nothing is broken, and in most cases nothing needs repairing. What needs deciding is whether the limit is catching the right traffic. A 429 served to a scraper hammering your login form is the system doing its job. A 429 served to Googlebot, a payment webhook, or a real customer on shared office Wi-Fi is a misconfiguration that costs you visitors and revenue.

Who is sending the 429?

The same status code comes from very different layers, and the fix depends entirely on which one fired. Look at the response headers and the body.

Clue	Who set the limit	What it usually means
Cloudflare-branded page, or error 1015 “You are being rate limited”	Cloudflare rate-limiting rule	A per-IP or per-path rule matched
JSON body from an API ("rate limit exceeded") with X-RateLimit-* headers	The API provider	Your integration exceeded its quota or burst limit
Plain nginx page	nginx limit_req / limit_conn	A server-level limit, often set tightly on login or search
WordPress or app login page	A security plugin or framework throttle	Too many failed logins from one IP
Only on your own outgoing calls	The third-party service you are calling	Your code is sending requests faster than allowed

The Retry-After header, if present, tells the client exactly how long to wait — either a number of seconds or an HTTP date. Well-behaved clients honour it. Clients that ignore it and retry immediately usually make the block last longer.

If you are a visitor

1. Stop refreshing. Every reload counts as another request and extends the block.
2. Wait a minute or two, then try once.
3. Disable a VPN or privacy relay. Hundreds of people can share one exit IP, and the limit counts them all as one visitor.
4. If you are on shared Wi-Fi — an office, a school, a café — the same thing applies: other people’s traffic is being counted against you.
5. If it persists for hours, contact the site. A block that long is either a mistake or a deliberate ban.

If it is your website returning 429

First confirm the scope. Load the site on a phone over mobile data and run it through the website checker. If an independent server gets a normal response and your office gets a 429, the limit is catching your shared IP, not the whole world.

The limit is set too low for real traffic

Rate limits copied from a tutorial are often tuned for an API, not a web page. A single page view can fire dozens of requests — HTML, CSS, scripts, fonts, images, API calls — and a limit of “10 requests per second per IP” can trip on a normal page load for anyone behind shared NAT.

Fix: limit the endpoints that need it — login, password reset, search, checkout, contact forms, and APIs — instead of the whole site. Static assets almost never need a per-IP limit. In nginx, attach limit_req to specific location blocks and add a burst so short spikes are absorbed:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    # …
}

The limit is counting the wrong IP

Behind a CDN or load balancer, every request can appear to come from the proxy’s address. The rate limiter then sees one enormous “visitor” and throttles everybody at once — a site-wide 429 that looks like an outage.

Fix: make the server read the real client address from the trusted header — CF-Connecting-IP behind Cloudflare, X-Forwarded-For behind most load balancers — and only trust it from the proxy’s IP ranges. In nginx that means set_real_ip_from plus real_ip_header.

Crawlers and monitors are being throttled

Search engines crawl in bursts. So do uptime monitors, link checkers, and SEO tools. If they receive 429s, Google slows its crawl rate, and a monitor may report the site as down even though human visitors see no problem.

Fix: exempt verified crawlers from aggressive limits, or give them a higher budget. A sustained 429 to Googlebot is read as “this server is overloaded”, and Google will fetch less of your site as a result.

A plugin or integration is calling your own site in a loop

A misbehaving cron job, a webhook that retries on every error, or a front-end script that polls an endpoint every second can generate enough traffic from one source to trip the limit — and it is your own code doing it.

Fix: check the access log for the top requesting IPs and user agents over the last hour. A single internal address at the top of that list is the culprit.

If your code is receiving 429s from an API

This is the other common case: your application calls Stripe, a mapping API, an AI model, or a CRM, and the provider is throttling you.

1. Read the headers. Retry-After, X-RateLimit-Remaining, and X-RateLimit-Reset tell you where you stand.
2. Back off exponentially, with jitter. Retry after 1s, 2s, 4s, 8s — each with a small random offset — rather than hammering a fixed interval. Synchronised retries from many workers are a classic way to stay rate-limited indefinitely.
3. Queue and batch. Most providers offer bulk endpoints. One request for 100 records beats 100 requests for one.
4. Cache what you can. Many 429s come from asking the same question repeatedly.
5. Check which limit you hit. Per-second burst limits and daily quotas need different fixes; the second one will not go away by waiting a few seconds.

429 vs 403 vs 503

• 429 Too Many Requests — you are allowed in, just not this often. Slow down and it clears.
• 403 Forbidden — you are not allowed in at all. Waiting will not help; a rule has to change.
• 503 Service Unavailable — the server is overloaded or in maintenance for everyone. It is about the server’s capacity, not your behaviour.

Why an unnoticed 429 matters

Rate limits fail silently from the owner’s side. You browse your own site, it works, and meanwhile a WAF rule is throttling a whole corporate network, a payment provider’s webhooks, or the crawler that decides your search rankings.

An outside check catches that. SitesRadar’s free plan monitors one site from an independent server and emails you when it starts answering with 4xx or 5xx codes, alongside SSL expiry, broken links, and DNS changes. For the broader picture of which error means what, see the 500, 502, and 504 guides.

FAQ

What does 429 Too Many Requests mean? It means the server, API, or CDN has received too many requests from you in a given time window and is refusing more until the window resets.

How long does a 429 last? As long as the Retry-After header says, if one is sent — often from a few seconds to an hour. Without it, most limits reset within one to fifteen minutes. Retrying repeatedly can extend the block.

How do I fix 429 Too Many Requests? As a visitor, stop refreshing, wait, and turn off any VPN. As a site owner, find which layer is limiting, raise or narrow the limit to the endpoints that need it, and make sure it counts the real client IP rather than your proxy’s.

Can a 429 hurt SEO? Yes, if Googlebot keeps receiving it. Google reduces its crawl rate when it sees 429s, so new and updated pages are discovered more slowly.

Is error 1015 the same as a 429? Yes. Cloudflare’s error 1015, “You are being rate limited”, is a Cloudflare rate-limiting rule returning HTTP 429 to the visitor.