A 429 Too Many Requests error means you have exceeded the server’s rate limit, and the server is temporarily refusing your requests until the rate limit window resets. Rate limits exist to protect servers from being overwhelmed by too many requests in a short period, whether from automated scripts, browser extensions, or simply refreshing a page too aggressively. The server’s response includes a Retry-After header specifying how long to wait before retrying.
The 429 status code was formally defined in RFC 6585 and is used by APIs, login systems, search interfaces, and any service that needs to control request volume. Unlike a 503 Service Unavailable, a 429 is not a server failure: the server is working fine, it is just rejecting your requests by policy. Waiting the specified retry period and then making a single clean request usually resolves it without any technical troubleshooting.
What Causes 429 Too Many Requests
The most common cause for regular users is browser extensions that make background requests. Price comparison extensions, tab managers that auto-refresh, and monitoring extensions all send requests to websites periodically without you initiating them. These background requests accumulate against the server’s rate counter and can trigger a 429 even when you are not actively browsing.
API integrations are the second major cause. If you use a website through an API key, the service enforces requests-per-minute or requests-per-day limits tied to your account or IP address. Exceeding these limits returns a 429 until the rate limit window resets. Most APIs document their limits in their developer documentation, along with the exact header format they use for Retry-After.
Shared IP addresses create a third scenario. If you access a service through a VPN, corporate network, or shared WiFi, many users share the same external IP address. If any user on that IP trips the rate limit, everyone behind that IP receives 429 responses. Switching to your personal mobile data connection, which has a unique IP, confirms whether this is the cause.
Wait for the Rate Limit to Reset
The most reliable fix is to stop making requests and wait. Most rate limits reset within 60 seconds to 15 minutes. Repeatedly refreshing the page during the lockout period extends it on many systems because each refresh counts as another request that resets the rate limit counter. Close the tab completely, wait at least two minutes, then make a single fresh request.
To find the exact wait time, open Chrome DevTools with F12, go to the Network tab, and reload the page while the 429 error is active. Click the failed request and look at the Response Headers panel. The Retry-After header shows the number of seconds to wait, and the X-RateLimit-Reset header (used by APIs like GitHub and Twitter’s API) shows the Unix timestamp when the limit resets.
Clear Browser Cache and Cookies
Session cookies tie your browser session to the rate-limited request count on the server. Clearing them gives you a fresh session identity, which the server treats as a new visitor with a clean rate limit counter. Press Ctrl+Shift+Delete, select All time, check Cached images and files and Cookies and other site data, then click Clear data.
Note that this works only on services that track rate limits per session rather than per IP address. If the server uses IP-based rate limiting, clearing cookies has no effect. Switching networks (from WiFi to mobile data) changes your IP and is the definitive test for IP-based rate limiting.
Disable Browser Extensions
Extensions that auto-refresh pages, monitor prices, check availability, or send periodic requests are common 429 triggers. These extensions run in the background and make requests you are not aware of. Go to chrome://extensions/ and disable all extensions, then reload the page. If the 429 clears, re-enable extensions one at a time to identify which one is sending excess requests.
Extensions that are particularly likely to cause 429 errors include Amazon price trackers, flight price monitors, social media feed refreshers, and any extension that checks for updates or new content on a timer. These should be configured to refresh less frequently or disabled on sites where you are experiencing rate limit errors.
Fix for Chrome
Go to chrome://extensions/ and use the toggle to disable each extension. Reload the affected page between each disable to isolate the culprit. Once identified, check the extension’s settings for a refresh interval option and increase it to reduce request frequency.
Fix for Edge
Go to edge://extensions/ and disable extensions using the same toggle approach. Microsoft Edge uses Chromium extensions from the Chrome Web Store, so the same categories of extensions apply. Extensions from the Microsoft Store may also send background requests.
Fix for Firefox
Go to about:addons and click Extensions. Disable each extension with its toggle. Firefox has its own set of background extensions, particularly monitoring and productivity tools, that can trigger 429 errors on rate-sensitive services.
Switch to a Different Network or Use a Different IP
If the rate limit is applied per IP address, switching networks gives you a fresh counter. Enable your phone’s mobile hotspot and connect your laptop to it. If the page loads without a 429, your original network’s IP address is rate-limited. This can happen on corporate networks where dozens of users share one external IP, or on VPN providers where many subscribers exit through the same IP.
VPNs can work both ways here. If your current VPN IP is rate-limited, switching to a different VPN server or disconnecting the VPN may resolve the issue. Conversely, if your home IP is rate-limited, connecting to a VPN gives you a different IP that is not currently limited.
Contact the Website Administrator
For persistent 429 errors on an API or service you use regularly, contact the service provider. Most services offer tiered rate limits where paid plans or registered API users receive higher request allowances. Provide your use case and typical request volume. Include your API key or account identifier so they can review your usage history and confirm whether your usage pattern is genuinely exceeding limits or whether a misconfiguration is causing false positives.
Advanced Fix: Check for Misconfigured Automation
If you run scripts, bots, or automated workflows that access websites (such as web scrapers, monitoring tools, or CI/CD pipelines that make API calls), review their request frequency. The standard practice is to implement exponential backoff: when a 429 is received, wait 2 seconds, retry, if another 429 is received wait 4 seconds, then 8, then 16. Most rate limiting documentation for major APIs specifies the recommended backoff strategy.
Also check if any WordPress plugins or CMS integrations are hammering an external API. Plugins that fetch exchange rates, weather data, or social media feeds sometimes send API requests on every page load rather than caching the responses, which can exhaust rate limits quickly.
Frequently Asked Questions
How long does a 429 Too Many Requests block last?
The duration depends on the service. Most consumer-facing services reset rate limits within 60 seconds to 15 minutes. API rate limits often reset on a rolling window (requests per minute or per hour) or at a fixed time each day. The Retry-After response header specifies the exact wait time. APIs that use daily limits, like many free-tier AI services, may block you for up to 24 hours.
Is a 429 error the same as being banned?
No. A 429 error is a temporary rate limit, not a permanent ban. After the rate limit window resets, your requests are accepted normally. A permanent ban would return a 403 Forbidden response, not a 429. If you continue to exceed rate limits repeatedly, some services escalate from 429 to IP-based blocks that are longer-lasting but still not permanent in most cases.
Can a 429 error cause data loss in API applications?
Yes, if your application does not handle 429 responses properly. API applications should always check for the 429 status code, read the Retry-After header, and pause execution for the specified duration before retrying. Applications that retry immediately or abort on 429 will either trigger longer blocks or lose the data that was being sent. Implementing exponential backoff prevents both outcomes.
Why am I getting 429 errors on a site I barely visit?
Browser extensions are the most likely explanation. Extensions run in the background and send requests to websites even when you are not actively browsing. A price tracker extension checking a product page every minute accumulates hundreds of requests per day to that site. Disabling all extensions and testing confirms this. The other possibility is a shared IP address from a VPN or corporate network where other users are generating high request volumes.
For server-side timeout errors that look similar to rate limiting, see the 504 Gateway Timeout guide. If you are hitting connection refused errors rather than rate limit responses, the ERR_CONNECTION_REFUSED article explains the difference. For redirect-related errors that occur alongside 429 responses, the ERR_TOO_MANY_REDIRECTS guide covers those scenarios.
