HTTP Error 429 Too Many Requests: Meaning & Fix

What Is HTTP Error 429?

HTTP 429 Too Many Requests means the server is rate-limiting you: you, your IP address or your app sent more requests than it allows in a period of time. It's temporary. The server is working; it's choosing not to answer you for now.

The code was added in RFC 6585 (2012) for exactly this case, and the response may carry a Retry-After header that says how long to wait. You'll meet it browsing busy sites, calling APIs, downloading in bulk, or on a VPN whose IP address many people share.

It's different from its neighbours: a 401 means you aren't signed in, a 403 means you aren't allowed, and a 429 means you're allowed, just too fast.

What Does a 429 Error Look Like?

The message depends on who answers. These are the ones people search for:

Unlike a 500 error, which means something broke on the server, a 429 is a client error in HTTP's terms: the server is protecting itself from too many requests.

How Rate Limiting Works

Rate limiting is a technique servers use to control how many requests a client can make within a time window. When the limit is exceeded, the server usually answers 429 (some answer 403 or 503 instead).

There are several common rate-limiting algorithms:

• Fixed Window — The server allows N requests per time window (e.g., 100 requests per minute). The counter resets at fixed intervals.
• Sliding Window — Similar to fixed window, but the time window slides with each request. This prevents bursts at window boundaries.
• Token Bucket — The server assigns tokens that refill at a steady rate. Each request consumes a token. When tokens run out, requests are rejected.
• Leaky Bucket — Requests are processed at a constant rate regardless of burst size. Excess requests queue up or get dropped.

Many APIs announce their limits in response headers. GitHub's, for example, are x-ratelimit-limit (requests allowed per hour), x-ratelimit-remaining, x-ratelimit-used and x-ratelimit-reset (when the window resets, in Unix seconds). An IETF draft proposes standard RateLimit and RateLimit-Policy headers for the same job.

Knowing which algorithm and window a service uses helps you design your client to stay inside the limit.

Common Causes of HTTP Error 429

The cause depends on who's seeing it:

How to Fix 429 Error (For Visitors)

If you are seeing a 429 error while browsing a website, here are the fixes you can try. Start with the simplest solution and work your way down.

1. Wait and Retry

The simplest fix is to wait. A 429 is temporary: the server is asking you to slow down, not banning you.

How long depends on the site's limit: some reset within a minute, others are hourly or daily. If the page or API sends a Retry-After header, that's the exact wait. Then load the page once.

Don't keep refreshing: every refresh is another request, and it counts against the same limit.

2. Clear the Site's Cookies

This rarely matters, but some sites count requests per session cookie. Clear that one site's cookies for a fresh session, without signing out of everything else:

• Chrome / Edge: open chrome://settings/content/all (Edge: edge://settings/content/all), search for the site and delete its data
• Firefox: click the padlock in the address bar → Clear cookies and site data…
• Safari: Safari → Settings → Privacy → Manage Website Data → find the site → Remove

After clearing, close and reopen the browser before visiting the site again.

3. Disconnect VPN or Proxy

If you are using a VPN or proxy, you might be sharing an IP address with hundreds of other users. When their combined requests exceed the server's limit, everyone on that IP gets rate-limited.

Try disconnecting your VPN and accessing the site on your regular internet connection. If the 429 error goes away, the VPN IP was the problem.

If you need the VPN, switch to another server location: its address may be shared by fewer people.

4. Disable Browser Extensions

Some extensions make requests to the sites you visit in the background: price trackers, SEO tools and auto-refresh extensions can add up to a rate limit. (Ad blockers usually do the opposite and cut requests.)

To test, open the site in an incognito/private window, where most extensions are off. Incognito also starts without cookies, so if the 429 disappears, an extension or a session-based limit is involved.

Disable extensions one by one to find the problematic one. In Chrome, go to chrome://extensions/ and toggle them off individually.

5. Check Whether Your IP Address Is Shared

Many people can share one public IP address: an office or school network, a mobile carrier's network (CGNAT), or a VPN server. Their requests count against the same limit as yours.

If you're on such a network, loading the site from your own home connection or mobile data tells you whether the shared address is the problem. If the limit is on your own address, wait for it to reset rather than switching networks to get around it. Check your current public IP with What Is My IP.

How to Fix 429 Error (For Developers)

If your code gets 429s, it's sending requests faster than the API allows. Handle it in this order: read Retry-After, back off with jitter, then reduce how many requests you make.

1. Implement Exponential Backoff

Exponential backoff is the standard retry strategy: instead of retrying immediately after a 429, double the wait each time (1 second, 2, 4, 8…), and add jitter, a random extra delay, so many clients don't all retry at the same moment.

This version uses Retry-After when the server sends a valid one, in either of its two formats, falls back to backoff with jitter otherwise, and gives up after a few tries. (In a browser calling another site's API, Retry-After is only readable if the API exposes it with Access-Control-Expose-Headers.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Respect the Retry-After Header

When a server sends Retry-After with a 429, it says exactly how long to wait. RFC 9110 allows two forms: a number of seconds, or an HTTP date.

Retry-After: 60 means wait 60 seconds. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT means wait until that time. Check it before your own backoff logic: the server knows better than your code.

In Python, handle both forms and stop after a few tries instead of recursing forever:

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. Cache API Responses

If your application makes the same API call multiple times, cache the response instead of hitting the API every time. This drastically reduces your request count.

Use an in-memory cache (like Redis or a simple Map) for frequently accessed data. Set a reasonable TTL (time-to-live) based on how often the data changes.

For example, if you are checking DNS records for a domain, the results likely will not change in the next 5 minutes — cache them.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Use Webhooks Instead of Polling

If you are polling an API repeatedly to check for changes (e.g., checking order status every 10 seconds), switch to webhooks if the service supports them.

With webhooks, the server pushes updates to your application when something changes — no need for constant polling. This can reduce your API calls from thousands per hour to just a handful.

Most modern APIs (Stripe, GitHub, Twilio, Shopify) support webhooks. Check the API documentation for webhook configuration.

5. Request Higher Rate Limits

If you legitimately need more API calls, contact the service provider. Many APIs offer higher rate limits for paid plans or verified applications.

When requesting higher limits, explain your use case and provide estimates of your expected request volume. Many APIs, Google's among them, have a form or a paid tier for higher limits.

Some APIs also offer bulk endpoints that let you fetch multiple resources in a single request, reducing total call count.

How to Fix 429 Error (For Website Owners)

If your visitors or API consumers are getting 429 errors, the problem is in your server configuration. Here is how to diagnose and fix it.

1. Tune Your Rate Limits

If real users hit 429s, find which layer answers first: your CDN or WAF, your web server, or your app. Then adjust that layer's limits.

In nginx, limit_req does the work. Note that it answers 503 by default: add limit_req_status 429; so clients know to slow down rather than assume the server is down:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

The burst parameter lets short spikes through without a 429; without it, a normal page load with many requests can hit the limit.

Apache has no built-in request-rate limiter: its mod_ratelimit limits bandwidth, not request counts, and the third-party mod_evasive answers 403. Use a reverse proxy, a WAF or your app for 429s. In Node.js, express-rate-limit answers 429 by default.

2. Whitelist Trusted IPs

If certain clients (monitoring services, payment processors, your own microservices) are getting rate-limited, whitelist their IP addresses.

In nginx, geo and map give trusted addresses an empty key, and nginx doesn't count requests with an empty key. This replaces the limit_req_zone line from the previous example:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

Don't rate-limit search engine crawlers by accident: Google treats a 429 as a server error and slows its crawling down (Google Search Central). Verify real Googlebot and Bingbot requests with a reverse DNS lookup confirmed by a forward lookup of that name, or exempt the crawlers' published IP ranges.

3. Check WAF and CDN Settings

If you use Cloudflare, AWS WAF, Sucuri or another security service, its rate-limiting rules may answer before your server ever sees the request.

Cloudflare shows visitors "Error 1015: You are being rate limited" when a rate limiting rule triggers. Find the rule in the dashboard's security rules, check its events, and raise the threshold or narrow its scope.

AWS WAF rate-based rules count requests per IP (or another key) over a 1, 2, 5 or 10-minute window, with a minimum limit of 10. A blocked request gets 403 by default; set a custom response of 429 so clients know to back off.

Look at the CDN's analytics to separate real visitors from bots before you change anything.

4. Optimize Server Performance

Some services rate-limit harder when they're under load, as a safety valve. Improving server performance lets you raise limits safely.

Key optimizations include: enable response caching to reduce backend load, use a CDN for static assets, add database query caching with Redis or Memcached, implement connection pooling for database connections, and scale horizontally with load balancing if traffic warrants it.

Use our HTTP Header Checker to verify your caching headers are set correctly.

429 vs Other HTTP Errors

It is easy to confuse the 429 error with other HTTP status codes. Here is how they differ:

The key distinction: 429 is deliberate and temporary: the server is choosing to turn you away for now. Most 5xx codes mean something failed on the server, though a 503 can also be planned maintenance or, in nginx, a rate limit.

How to Prevent 429 Errors

Prevention is better than cure. Here are best practices to avoid 429 errors in the first place:

• Read API documentation — Know the rate limits before writing code. Most services publish their limits clearly.
• Monitor your usage — Track X-RateLimit-Remaining headers to know how close you are to the limit.
• Batch requests — Use bulk endpoints when available instead of making individual calls.
• Distribute requests — Spread API calls evenly over time instead of sending bursts.
• Use API keys — Authenticated requests usually get higher rate limits than anonymous ones.
• Implement circuit breakers — If you get repeated 429s, stop sending requests entirely for a cooldown period.
• Test with rate limit simulators — Simulate 429 responses in development to ensure your error handling works.
• Log 429 responses — Track when and where rate limiting occurs to optimize your request patterns.