How to Fix 429 Too Many Requests Error

By ErrorFix · Updated October 20, 2026 · 4 min read

What 429 Too Many Requests means

The 429 status is the server's way of saying "slow down." Every site has a speed limit: a maximum number of requests it will accept from one visitor within a sliding window — say, sixty requests per minute. Cross that line and the server stops answering, serving a 429 page instead, until the window slides forward and your count drops back under the limit. It is a deliberate protection feature, not a crash. Sites use it to survive traffic spikes, block brute-force login attacks, and stop scrapers from draining their resources.

What makes 429 frustrating is that the requests do not have to be deliberate. A tab left auto-refreshing a live scoreboard, a browser extension rechecking prices, a WordPress admin page with chatty AJAX calls, or a VPN exit IP shared by hundreds of strangers — all of them rack up request counts you never see. And once the limit trips, the natural response is to hammer the refresh button, which is the worst thing you can do: every reload adds to the count and restarts the clock on your block.

Common causes

• Rapid manual refreshing: smashing F5 on a slow page — during a sale, a ticket drop, or a form that seems stuck — can easily cross a per-minute threshold meant to catch bots.
• Auto-refresh tabs and extensions: price trackers, live-score widgets, and auto-reload extensions fire requests on a timer. Several of them open at once look exactly like a botnet to the rate limiter.
• Scripts, scrapers, and API calls: a Python script polling an endpoint in a tight loop, or an unauthenticated API client hammering retries after a failure, burns through the (deliberately low) anonymous quota fast.
• A shared IP address: VPN exit nodes, office networks, dorm Wi-Fi, and mobile carriers put many users behind one public IP. Rate limiters count the IP, so strangers' traffic counts against your allowance.
• An overly aggressive limiter: sometimes the site is at fault — a security plugin, a Cloudflare rate-limiting rule, or an nginx limit_req set tight enough that normal human browsing trips it. If a single calm page visit throws a 429, the threshold needs tuning.

How to fix 429 Too Many Requests — step by step

The whole fix takes about twenty minutes: stop the flood, wait out the window, and rule out your network or scripts.

1. Stop the request storm and wait out the window. Close the tab and every other tab hitting the same site, and stop any auto-refresh extension, price tracker, or script you have running. Rate limits are time windows, so the counter resets on its own — most blocks lift in one to fifteen minutes. Check the Retry-After value if the site sends one: that is exactly how many seconds to wait before trying again.
2. Reload with a clean slate, then test one request. A stuck browser session can keep re-firing the same blocked requests. In Chrome, open Settings, then Privacy and security, then Delete browsing data, and clear "Cookies and other site data" plus "Cached images and files" for the last 24 hours. Restart the browser, open the page once, and resist the urge to hammer refresh — repeated reloads just restart the rate-limit clock.
3. Check whether your VPN or shared connection is the trigger. VPN exit nodes and mobile or office networks are shared by hundreds of users, and rate limiters often count the shared IP instead of you. Turn the VPN off and try the direct connection, or switch from Wi-Fi to mobile data (and back) so you come from a different public IP. If the error disappears, the limiter flagged the shared address, not your behavior.
4. If you run the site, find the limiter that is firing. The 429 comes from a specific layer, so identify it before changing anything. Open the browser's Network tab, trigger the error, and read the response headers: Retry-After and X-RateLimit-Remaining confirm a limiter, and the Server header points at it. Then check each candidate: nginx limit_req_zone and limit_req directives in /etc/nginx/nginx.conf, Apache mod_evasive or mod_ratelimit, Cloudflare Dashboard under Security then Rate limiting rules, or a WordPress security plugin like Wordfence under Firewall then Rate Limiting.
5. Tune the limit instead of disabling it. Turning rate limiting off invites bot abuse, so calibrate it. In nginx, raise the burst value and add nodelay on the limit_req line so legitimate bursts pass while abuse still trips it. In Cloudflare, lift the rule threshold or add a skip rule for your own logged-in traffic. In Wordfence, whitelist your office IP and raise the "Requests per minute" value. Change one layer at a time and retest, so you know which change actually fixed it.
6. For API callers, authenticate and back off. Anonymous API calls live under the strictest quotas — authenticate with an API key or OAuth token, which usually multiplies your allowed request rate many times over. Then read the API's rate-limit headers (X-RateLimit-Remaining and Retry-After) and honor them: when the remaining count hits zero, pause until the window resets, and retry failed calls with exponential backoff — wait 1, 2, 4, 8 seconds — instead of blasting retries at full speed.

Did this fix it? Quick checklist

• All auto-refresh tabs, extensions, and scripts hitting the site are closed, and you waited out the full rate-limit window
• Cookies and cached files for the site are cleared, and a single calm page load — not a refresh storm — was tested
• The VPN is off (or a different network was tried) to rule out a shared-IP block
• Site owners: the firing limiter is identified and tuned up, not disabled; API callers authenticate and honor Retry-After

One more spot to check if it still fails: open the page in a private or incognito window with all extensions disabled. If the private window loads fine while your normal profile throws a 429, an extension is firing background requests you did not know about — disable extensions one by one until the culprit shows itself. And if the 429 appears only on your home network but never on mobile data, your router or a device on your LAN may be hammering the site (a misconfigured smart-home hub polling a cloud API is a classic) — a router reboot and a check of your network's connected devices usually finds it.