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

A 429 Too Many Requests error message means you hit a rate limit. The server received your request, but it is deliberately throttling your excessive requests to prevent overload or enforce API quotas.

Servers typically track this traffic by IP address, user account, or API key. As a result, one aggressive background script can easily trigger a block for all other user agents and applications using the same network or account.

This guide covers how to handle these blocks whether you’re browsing a website or writing code to manage API calls.

What Is the 429 Too Many Requests Error?

The 429 Too Many Requests status code is a client error defined in section 4 of RFC 6585 , caused by sending too much traffic in a given timeframe.

For standard rate limits, the issue resolves itself once enough time passes. But if you hit a monthly billing quota, you might need to upgrade your account or pay for overages instead of just waiting.

When a server blocks your traffic, it might include HTTP headers to help you adjust your code. The optional Retry-After header, standardized in RFC 9110 , tells you how many seconds to wait or gives a precise date to resume operations.

Many APIs also use X-RateLimit headers, a common convention rather than a standard. These show your total allowed limit, how many requests you have left, and when the limit resets. If the server provides these details in the return response, it removes the guesswork from debugging.

An IETF draft would standardize this as RateLimit and RateLimit-Policy headers, but it isn’t an RFC yet, so watch the remaining-requests value your API sends and slow down before it reaches zero.

Once the reset time arrives or you upgrade your plan, the server will accept new requests normally.

What Causes 429 Errors and How Rate Limits Work

Servers use rate limits to prevent overload and mitigate DDoS attacks. They measure your incoming traffic against specific limits over a set time. To do this, systems usually rely on a few common algorithms.

• A fixed window resets your request count at set intervals, like every minute, so retrying before the next reset won’t help.
• A sliding window tracks your traffic continuously on a rolling basis, so capacity comes back gradually as older requests age out.
• A token bucket allows short bursts of heavy traffic but enforces a steady baseline request rate overall, so requests get through again once you slow down to that rate.

Systems tie these limits to identifiers like your IP address, account, session token, API key, or even a browser fingerprint, and that decides which fix works. While standard rate limiting is the most common cause of a 429 error, you might also see one if you exhaust a billing quota.

Authenticating can also raise your limit: GitHub’s REST API allows 60 unauthenticated requests per hour, but 5,000 per hour with a token.

Note that if a firewall or bot detector flags your traffic as part of an attack, such as brute force attacks on a login page, it will usually return a 403 Forbidden instead of a 429.

How to Fix a 429 Error in Your Browser

If you see a 429 error code while browsing a website, the best course of action is to do nothing; simply wait for a few minutes. If you start refreshing the page erratically, those multiple requests will often cause you to wait even longer.

To see exactly how long to wait, open your browser’s developer tools (F12), go to the Network tab, reload the page once, and select the request with status code 429. If its response headers include a Retry-After header, it tells you when to try again.

Many guides suggest clearing your cache and cookies. While this will not fix a block based on your IP address, it can sometimes stop a glitchy website script that is stuck in a loop and spamming the server.

Servers often track limits by IP address, so if you use a public Wi-Fi network or a VPN, you share that IP with many other people. Switching to a different network, like your mobile data connection, gives you a new IP and usually restores access.

You can also trigger this error accidentally on your own. A forgotten tab that constantly refreshes or a poorly coded browser extension can send too many background requests, so close unused tabs and keep your browser extensions up to date.

If you are on mobile devices, toggling airplane mode on and off will often get you a new IP address from your carrier, which clears a limit tied to your IP.

How to Handle 429 Errors in Code

Good software implements retry logic to handle 429 errors by checking the Retry-After header for a wait time before trying the request again. Only if the server doesn’t send one should you fall back to an exponential backoff strategy.

With exponential backoff, you double your wait time each time a request fails, for example 1, 2, and then 4 seconds. Always set a maximum number of retries to prevent infinite loops.

When multiple scripts wait for the exact same delay, they can wake up simultaneously and overload the server again. To prevent this, add small random delays, called jitter, to each wait.

Also, make sure your write operations are safe to repeat. A 429 usually means the request wasn’t processed, but retry code often also retries timeouts, where a POST may already have gone through. Without an idempotency key, that can create duplicate database records.

Here is a practical example in JavaScript. It reads the Retry-After header as either seconds or a date, falls back to exponential backoff when the header is missing, and adds random jitter to the delay:

async function fetchWithRetry(url, options = {}) {
    let retries = 3;
    let delay = 1000;
    while (true) {
        const response = await fetch(url, options);
        if (response.status === 429) {
            if (retries === 0) {
                throw new Error('Request failed: maximum retries exceeded');
            }
            const retryAfter = response.headers.get('Retry-After');
            let waitTime = delay;
            if (retryAfter && !isNaN(retryAfter)) {
                waitTime = parseInt(retryAfter, 10) * 1000;
            } else if (retryAfter && !isNaN(Date.parse(retryAfter))) {
                waitTime = Math.max(0, Date.parse(retryAfter) - Date.now());
            }

            await new Promise(resolve => setTimeout(resolve, waitTime + Math.random() * 500));
            retries--;
            delay *= 2;
        } else if (!response.ok) {
            throw new Error(`HTTP error! status: ${response.status}`);
        } else {
            const data = await response.json();
            return data;
        }
    }
}

A similar approach in Python also reads a Retry-After header that contains a date instead of a number, and stops as soon as it runs out of retries:

import time
import random
import requests
from email.utils import parsedate_to_datetime

def get_wait_time(retry_after, default):
    if retry_after and retry_after.isdigit():
        return int(retry_after)
    try:
        return max(0, parsedate_to_datetime(retry_after).timestamp() - time.time())
    except (TypeError, ValueError):
        return default

def fetch_with_backoff(url):
    retries = 3
    delay = 1
    while True:
        response = requests.get(url, timeout=10)
        if response.status_code == 429:
            if retries == 0:
                raise Exception("Request failed: maximum retries reached")
            wait_time = get_wait_time(response.headers.get('Retry-After'), delay)

            time.sleep(wait_time + random.uniform(0, 0.5))
            retries -= 1
            delay *= 2
        else:
            response.raise_for_status()
            return response.json()

429 Errors in Web Scraping and Automation

Scraping scripts often hit 429 errors because they fire off hundreds of requests in the time a human clicks once. If a site provides rate limit headers, you can use them to set a safe concurrency limit for your code. However, many websites don’t send these headers, so you have to rely on conservative pacing and exponential backoff strategies instead.

If a server limits requests by IP address, pacing alone might not be enough. One of the methods to continue with your project is to use rotating residential proxies that change the IP on every request or keep the same one for a sticky session of up to 7 days. Proxy rotation spreads your requests across many IPs, but it won’t help against limits tied to your account or API key.

from $1.75/GB

Global Pool, Precise Targeting, Zero Contracts

Premium Residential Proxies

Buy Residential Proxies

Rotation also doesn’t replace pacing. If your own concurrency caused the 429, rotating IPs just spreads the problem across more addresses. Keep respecting the rate limits, cache your results, and follow the rules outlined in the robots.txt file.

Additionally, be aware that Content Delivery Networks can enforce rate limits at the edge, stopping most traffic spikes before they reach the website’s own server. For example, Cloudflare shows an Error 1015 page when a site’s rate limiting rule blocks you. It’s the same HTTP 429 status code under a vendor name, sent by Cloudflare instead of the origin server.

FAQ