How to Fix 429 Too Many Requests (Visitors, Site Owners, and APIs)

429 Too Many Requests is the only common HTTP error that means the server is working exactly as designed. Something counted your requests, decided you had sent too many in too short a time, and refused the next one on purpose. Nothing crashed, nothing is misconfigured in the usual sense, and the server is up.

That makes the fix unusual too. You are not repairing a failure, you are working out which rate limiter fired, who it thinks you are, and whether its idea of "too many" matches reality. On a site you own, the answer is very often that a limiter is counting thousands of different visitors as one person, or that it is counting the 40 files a single page load requests as 40 separate attempts.

This guide covers what a 429 actually tells you, a short list of visitor fixes that work, a diagnosis that identifies the responsible layer in under a minute, the three causes behind nearly every unexpected 429, how API clients should handle it, and what it does to your search rankings. If you do not run the site, jump to the visitor section.

What 429 Too Many Requests Actually Means

The 429 status code was defined in RFC 6585 in 2012 for one purpose: telling a client it has exceeded a rate limit. Every rate limiter works the same basic way. It picks a key that identifies the client, counts requests against that key over a window of time, and rejects requests once the count passes a limit.

Almost every unexpected 429 comes from one of those three settings being wrong for real traffic:

• The key is wrong. The limiter identifies clients by IP address, but every request arrives from the same IP, such as a proxy, a load balancer, or Cloudflare. Everyone shares one bucket, and it empties in seconds.
• The limit or window is wrong. The numbers were chosen for a login form and applied to the whole site, or chosen by reading a config example without knowing how the limiter measures time.
• The limit is right. Someone really is sending too many requests, whether a scraper, a brute force script, an aggressive crawler, or your own code stuck in a retry loop.

A well behaved 429 also includes a Retry-After header, which tells the client how long to wait. It can be a number of seconds, such as Retry-After: 60, or a date. Many limiters leave it out, which is why so many clients handle a 429 badly.

How It Differs From Similar Errors

Rate limiting does not always show up as a 429, and a 429 is not the only way a server says "slow down". The useful question is whether the refusal depends on how many requests you sent.

If You Are a Visitor, Not the Site Owner

A 429 is about you, or about the address you are connecting from, so unlike most server errors there are things on your side that genuinely help. Work through these in order.

Stop Refreshing and Wait

Most limits reset within one to fifteen minutes. Every refresh during that time is another request against the limit, and some limiters extend the block each time they reject you. Close the tab, wait a few minutes, and try once. If the page told you how long to wait, wait that long.

Turn Off Your VPN

VPN exit servers carry traffic for hundreds or thousands of users from one IP address. To a site limiting by IP, all of those people look like a single very busy visitor. Disconnect and reload, or switch to a different VPN server. The same applies to office networks, schools, and some mobile carriers, which put many people behind one shared public address.

Close Other Tabs and Disable Busy Extensions

Ten tabs open on the same site all poll it in the background. Extensions that check prices, track stock, or auto refresh pages can send a steady stream of requests you never see. Close duplicate tabs, then try an Incognito window, which runs without most extensions. If it works there, disable extensions one at a time to find the busy one.

Know When It Is Tied to Your Account

On logged in services such as AI chat tools, social networks, and developer APIs, the limit is usually attached to your account, not your network. Switching Wi-Fi or turning off a VPN will not reset it. Only waiting for the window to pass, or moving to a plan with a higher limit, will.

Diagnose It in Three Steps

A typical site has three or four places that can return a 429: a CDN or WAF, the web server, a security plugin, and the application itself. They all send the same status code. The first job is finding out which one is responsible, because fixing the wrong layer changes nothing.

Step 1: Read the Response Headers and Body

curl -s -D - -o body.txt https://example.com/ | grep -iE "^HTTP|^server|retry-after|ratelimit|cf-ray"
head -c 500 body.txt

The headers and body almost always name the layer that fired:

Step 2: Measure the Limit

Send a controlled burst and watch where the 429s begin. Only do this against a site you own:

for i in $(seq 1 30); do
  curl -s -o /dev/null -w "$i %{http_code} %{time_total}s\n" https://example.com/
done

Step 3: Find the Key in the Logs

Nginx logs every rejection in the error log, including the zone and the client key it counted:

sudo grep "limiting requests" /var/log/nginx/error.log | tail -n 5

# Example output
limiting requests, excess: 20.460 by zone "perip", client: 172.70.34.12, server: example.com, request: "GET /cart/ HTTP/1.1"

Look closely at client. If it is a Cloudflare address, your load balancer, or a private address like 172.17.0.1 or 10.0.0.5, you have found cause one. To see who is actually generating the most requests, count 429s and top IPs in the access log (this assumes the default combined log format):

# How many 429s per hour
sudo awk '$9 == 429 {print substr($4, 2, 14)}' /var/log/nginx/access.log | sort | uniq -c

# Which IPs received them
sudo awk '$9 == 429 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Which URLs were limited
sudo awk '$9 == 429 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Cause 1: Every Visitor Looks Like the Same IP

This is the most damaging cause, because it does not limit one heavy user. It limits your entire audience at once, usually right when traffic is highest. It happens whenever a rate limiter keys on the connecting IP address and something sits in front of the application that makes every connection come from the same place.

The classic trigger is putting a site behind Cloudflare, a load balancer, or a reverse proxy without telling the layers behind it where the real client address is. A limit of 10 requests per second per visitor becomes 10 requests per second for the whole site, and a normal traffic spike turns into a wall of 429s.

Nginx Behind Cloudflare or a Load Balancer

$binary_remote_addr is the address of whatever connected to Nginx. Behind Cloudflare, that is a Cloudflare edge server. Use the real IP module so Nginx replaces it with the visitor's address before rate limiting runs:

# In the http block. Add every range from https://www.cloudflare.com/ips/
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ...remaining IPv4 and IPv6 ranges...
real_ip_header CF-Connecting-IP;

# Behind an AWS ALB or your own proxy instead:
# set_real_ip_from 10.0.0.0/8;
# real_ip_header X-Forwarded-For;
# real_ip_recursive on;

Application Frameworks Behind a Proxy

Application level limiters have the same problem and their own setting to fix it:

Real Visitors Who Share an Address

Even with real IPs working, some legitimate visitors share one. Mobile carriers use carrier grade NAT that puts many phones behind one public IPv4 address, and offices, universities, and VPN providers do the same. If your 429s cluster on a handful of IPs that turn out to be a mobile carrier or a customer's office, raise the per IP limit or key logged in users by account instead of IP. Per IP limits work best as a loose safety net, with tight limits reserved for specific actions.

Cause 2: The Limit Does Not Match Real Traffic

The second most common cause is a limit that is reasonable on paper and wrong in practice. A number that makes sense for a login form gets applied to every request, or a config gets copied without understanding how the limiter measures time.

A Page Is Not One Request

Loading one page in a browser can easily trigger 30 to 100 requests: stylesheets, scripts, fonts, images, and API calls from the page itself. A modern single page app may fire a dozen API requests just to render its first screen. If a limit of "20 requests per second" is applied to location /, it counts all of them, and a visitor clicking quickly between two pages is blocked. Exclude static files from general rate limiting and put tight limits only where they belong:

limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_status 429;

server {
    # Loose limit for dynamic pages, with room for bursts
    location / {
        limit_req zone=general burst=50 nodelay;
        # ...
    }

    # No rate limit on static assets
    location ~* \.(css|js|png|jpg|jpeg|webp|svg|woff2?)$ {
        expires 30d;
    }

    # Tight limit only where brute force happens
    location = /wp-login.php {
        limit_req zone=login burst=5 nodelay;
        # ...
    }
}

The Nginx Burst Trap

This catches more people than any other setting. Nginx does not count requests over a window and reset. It enforces the rate evenly. rate=60r/m does not mean "60 requests in any minute", it means "one request per second". rate=10r/s means one request every 100 milliseconds. Without a burst value, two requests arriving in the same instant break the limit, and the second one is rejected.

burst=50 lets up to 50 extra requests queue above the rate. Adding nodelay serves those queued requests immediately instead of spacing them out, which is what you want for page loads. A limit with no burst is almost always a mistake on anything a browser touches.

WordPress: admin-ajax.php and Logged In Editors

On WordPress, many plugins and the Heartbeat API send repeated requests to /wp-admin/admin-ajax.php in the background. An editor with several admin tabs open, or a page builder autosaving, can generate a steady stream from one IP. If your security plugin or host rate limits that path, editors get 429s while the public site looks fine. Check the plugin's rate limiting or brute force settings first, and ask your host whether their firewall limits admin-ajax.php, since many hosts apply their own rules you cannot see in WordPress.

Legitimate Integrations and Webhooks

Payment processors, shipping providers, and other services send webhooks in bursts, often from a small set of IPs. A limiter that blocks them causes failed orders that do not look like an error on your site at all. Exempt verified webhook endpoints from general rate limits and validate them by signature instead.

Cause 3: Someone Really Is Sending Too Many Requests

Sometimes the limiter is right. If step three showed a handful of IPs or user agents responsible for most of the 429s, the rate limit is doing its job, and the question becomes whether that traffic is worth serving at all.

• Brute force against logins: repeated POST requests to /wp-login.php, /xmlrpc.php, or your app's login endpoint. Keep the tight limit, and block xmlrpc.php entirely if nothing you use needs it.
• Scrapers and AI crawlers: bursts of GET requests across many URLs from cloud provider IP ranges. A 429 is a polite and effective answer. For crawlers that ignore it, block by user agent or ASN at your CDN.
• Search filters and query strings: bots crawling every combination of filters and sort orders on a shop or listing page. Rate limit the filtered URLs and disallow them in robots.txt.
• Your own code: a frontend retry loop, a cron job that calls your own API without pausing, or a monitoring script someone wrote years ago. Check whether the top IP in your logs is one of your own servers.

When abusive traffic keeps pushing the site toward its limits, a rate limit at the edge is far cheaper than one on your server. A Cloudflare rate limiting rule rejects the request before it uses any of your CPU, while an application level throttle still runs your framework for every rejected request. If the load is causing slowdowns or crashes as well as 429s, our guide to what causes website downtime covers the wider picture.

If You Are Getting 429s From an API

When your code calls someone else's API, you cannot change their limit. You can only stop exceeding it and recover gracefully when you do. Retrying immediately is the worst possible response, because every retry counts against the same limit and keeps you blocked for longer.

Read the Rate Limit Headers

Most APIs tell you exactly where you stand on every response, not just on the 429:

Retry-After: 30
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 30

# Older style, used by GitHub and many others
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1789653600

Watch Remaining and slow down before it reaches zero. Note that the reset value is a number of seconds in some APIs and a Unix timestamp in others, so check the documentation before using it.

Back Off Exponentially, With Jitter

When you get a 429, wait for Retry-After if it is present. If it is not, wait one second, then two, then four, and so on up to a cap, adding a random amount each time. The randomness matters: without it, every worker that was limited at the same moment retries at the same moment and hits the limit together again.

import random
import time

import requests


def get_with_backoff(url, max_attempts=6):
    for attempt in range(max_attempts):
        response = requests.get(url, timeout=30)
        if response.status_code != 429:
            return response

        retry_after = response.headers.get("Retry-After")
        if retry_after and retry_after.isdigit():
            delay = int(retry_after)
        else:
            delay = min(2 ** attempt, 60)
        time.sleep(delay + random.uniform(0, 1))

    response.raise_for_status()
    return response

Beyond retries, the lasting fixes are making fewer calls: cache responses that do not change often, use batch endpoints where the API offers them, replace polling with webhooks, and run multiple workers through a shared queue so their combined rate stays under the limit. The last one is easy to miss. Five workers that each respect a limit of 10 per second will send 50 per second together.

What 429s Do to Googlebot and Your Rankings

Google treats a 429 as a signal that its crawler is overloading your server, in the same group as 500 and 503 responses. Googlebot slows its crawl rate in response. A short burst of 429s is harmless and is a legitimate way to reduce crawling for a while. The problem is a limiter that keeps rejecting Googlebot for days: pages that persistently return server error codes can eventually be dropped from the index.

If Search Console shows a rise in server errors or a falling crawl rate after you added rate limiting, check your logs for 429s served to verified Googlebot IPs, and loosen the limit for them. Never serve a 429 on your homepage or key landing pages as a permanent way to block crawlers. Use robots.txt for that.

How to Stop It From Happening Again

Rate limiting failures have a nasty property: the site looks completely healthy to you. Your own requests are few, so you are never limited, while visitors behind a busy proxy or a shared carrier IP are turned away. The limiter only fires when traffic is high, which is exactly when a bad limit costs the most. And visitors who see a 429 do not report it. They leave.

Test Your Limits Before Real Traffic Does

After changing any rate limit, load your heaviest page in a browser with the network tab open and click quickly through a few pages. Then run the burst test from step two. If you just put a site behind Cloudflare or a load balancer, confirm the client in your Nginx logs is a real visitor IP before traffic arrives.

Monitor From Outside

An external uptime monitor sends a real HTTP request from a different network on a fixed schedule. A monitor checking every minute or every five minutes will never trip a sensible rate limit by itself, so if its checks start returning 429, your limiter is catching far more than it should, and real visitors are almost certainly being blocked too. Notifier counts a 429 as a failed check and alerts you with the exact time it started, which you can match against the rejections in your logs.

Add the URL, and every check sends a real request that has to get past your rate limits.

Monitor more than the homepage. A cached homepage can be served by your CDN without ever reaching the limiter, while your login page, search, or API is rate limited behind it. If your product has an API, add a monitor for a lightweight endpoint as described in our guide to monitoring an API endpoint. Rising response times are worth watching too, since a site that is struggling under load is often the one where someone reaches for a tighter limit, as covered in how to monitor website response time.

The incident history shows when checks started failing and how long it lasted.

Get the Alert Where You Will See It

Notifier sends email, SMS, phone call, and Slack alerts on every plan, including the free tier, and a recovery alert when checks pass again. SSL certificate and DNS monitoring are included free on every plan as well, so an expiring certificate on the same site does not become the next outage.

The alert includes the time the incident started, so you know which minute of logs to read.

How the Common Tools Compare

Rate limit problems are short and tied to traffic peaks, so check frequency and alert channels matter most. Here is how the usual options compare on their free plans:

Pricing changes, so verify before committing. Our comparison of free website monitoring tools covers each free tier in detail, and how to set up website monitoring walks through setup in about five minutes. If rate limits are only one of several problems appearing under load, why your website keeps going down covers the patterns behind recurring outages.

Frequently Asked Questions