429 Too Many Requests

The short version: Ease off. A 429 means you blew past a rate limit, so stop retrying right away. Look in the response for a Retry-After header and wait that long before your next attempt. If the API is yours, send a clear Retry-After and set limits sized to real traffic.

Key takeaways

• A 429 tells you the server is fine and is throttling you on purpose. Retrying harder makes it worse; the cure is to back off.
• Look at the Retry-After header before anything else. It states the exact wait in seconds or as an HTTP date, and obeying it is the surest way to get unblocked.
• Plenty of APIs add X-RateLimit-* headers showing your quota, how much is left, and when the window resets. Use them to stay under the ceiling rather than guessing.
• Watch the scope. A 429 on a single path is a per-endpoint or per-key limit; a 429 on everything usually points to an IP or account limit, often from a shared NAT, VPN, or proxy.
• RFC 6585 forbids caching a 429, so every retry gets a fresh verdict. That is why a sensible backoff eventually gets through.

Error type

HTTP 4xx client error

Whose side

Either: too many requests, or a tight limit

Fix difficulty

Easy to moderate

Common cause

Rate limit exceeded in a time window

What does 429 Too Many Requests mean?

A 429 Too Many Requests is a client-error response from RFC 6585. It means you sent too many requests in a given span of time and are now being rate limited. The server is up and reachable. It is throttling you on purpose, to shield itself from overload or abuse. That limiting can run server-wide, per endpoint, per IP, per user, or per API key, which is why the same site can return 429 on one path while serving another normally.

A polite 429 carries a Retry-After header stating precisely how long to hold off, as a count of seconds or an HTTP date. Scope is the real question. A 429 aimed at one client (your IP or API key) clears as soon as you slow down, whereas a 429 served across the board often means the whole service is shedding load. The spec also bars caching of a 429, so each retry gets evaluated afresh.

429

HTTP status code

Retry-After

Header telling you when to retry

RFC 6585

Spec that defines the 429 code

4xx

Client-error class it belongs to

How the 429 Too Many Requests error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com/api

429

Too Many Requests

You have sent too many requests in a given amount of time.

• 429 Too Many Requests
• HTTP Error 429
• Error 429
• Rate limit exceeded
• 429 Too Many Requests (you have sent too many requests)
• HTTP 429

429 vs 503 and 403

All three can block a request, but they mean very different things and point to different fixes.

Rate-limit headers you may see with a 429

These headers tell you how long to wait and how much of your quota is left, so check for them before retrying.

What causes 429 Too Many Requests?

• You blew past an API rate limit, say a documented requests-per-minute quota
• A loop that refreshes, scrapes, or polls an endpoint far too fast
• One public IP shared behind NAT, a corporate proxy, or a mobile carrier, so a crowd of users registers as a single client
• A bot, plugin, or background job pounding the server on a tight schedule
• DDoS or bot-protection rules (Cloudflare and the like) throttling traffic that looks suspicious
• A burst of login or password-reset attempts hitting an abuse limit
• A monitor or crawler checking far more often than the limit permits

How to find the cause fast

1. Read the response headers. Retry-After and any X-RateLimit-* values spell out the wait and the quota
2. Work out whether it is one endpoint or all of them: a single path means a per-resource limit; everything means an IP or account limit
3. See whether you are sitting behind a shared IP, VPN, or proxy that other clients use too
4. Pull your own request rate for the last minute and hour, in case a script or a stray tab is looping

Terminal

curl -sI https://example.com/apiHTTP/1.1 429 Too Many RequestsRetry-After: 60# you hit the rate limit; wait the Retry-After seconds

How 429 Too Many Requests looks from the outside

From outside, a 429 reads nothing like a real outage. The server answered; it just turned you away for now. A monitor that calls every non-200 a failure will mark a 429 as down even though the site is healthy for ordinary visitors. The reverse is a trap too: a monitor that pounds an endpoint, or a wave of checks from one IP, can trip a rate limit itself and produce the 429 it later reports. Reasonable intervals and a dedicated, allowlisted monitoring path are what keep the signal honest.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 429 Too Many Requests

If you are a visitor

1. Wait. Honor the Retry-After value before you reload, and if there is none, give it a minute at least
2. Quit mashing refresh or resubmitting forms in a hurry; it only resets the clock
3. Switch off pushy browser extensions or auto-refreshers firing requests in the background
4. Drop a shared VPN or proxy IP, or change networks, so you stop getting lumped in with everyone else on it
5. Calling an API? Slow the request rate and add backoff between calls
6. Clear the website's cookies, since some limits track a session token
7. Still happening on normal browsing? Get in touch with the website so they can review their rules

If you run the website or API

1. Send an accurate Retry-After header (and ideally X-RateLimit-*) every time, so clients can comply
2. Size your rate limits to real usage instead of picking arbitrarily low numbers
3. Allowlist clients you trust: your own monitors, partners, and the good bots you recognize
4. Put caching and a CDN in front so repeat requests never touch the rate-limited origin
5. Split human traffic from automated, and favor per-API-key limits over per-IP to spare shared-NAT users
6. Add capacity or lift limits when legitimate traffic spikes (launches, campaigns)
7. Return 429, not 503, for rate limiting so the cause is unambiguous; in nginx, set limit_req_status 429

Still not fixed? Next steps

• Find the published limit in the API docs, then queue or throttle your client to stay under that requests-per-minute or per-hour quota. Blind retries just keep tripping it.
• Behind a shared IP (corporate NAT, VPN exit node, mobile carrier)? Move to an authenticated, per-API-key path or a different network so strangers' traffic stops being charged to you.
• When the 429 shows up during ordinary browsing rather than an API call, reach out to the website owner. An over-tight WAF or bot rule (Cloudflare is a frequent culprit) may be throttling real visitors, and only they can loosen it.
• Running the service yourself? Send an accurate Retry-After (and ideally X-RateLimit-*), and allowlist clients you trust, your own monitors and known search crawlers among them, so genuine traffic never gets throttled.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Read the Retry-After header and back off

# Show response headers so you can see the limit and the wait time
curl -sS -D - -o /dev/null https://api.example.com/v1/items

# Typical 429 response:
#   HTTP/1.1 429 Too Many Requests
#   Retry-After: 60
#   Content-Type: application/json
#
# Retry-After can be seconds (60) or an HTTP date.
# Wait the stated time, then send ONE request, not a burst.

Return 429 with nginx rate limiting

# In the http block: 30 requests/sec per client IP, 10MB state zone
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

server {
  location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;          # default is 503; 429 is correct here
    proxy_pass http://backend;
  }
}
# burst=20 absorbs short spikes; excess requests get 429.

Exponential backoff with jitter (pseudo-code)

delay = 1
for attempt in 1..6:
    res = send_request()
    if res.status != 429:
        return res
    wait = res.header("Retry-After") or delay
    sleep(wait + random(0, 1))     # jitter avoids a synchronized retry storm
    delay = delay * 2              # 1s, 2s, 4s, 8s, 16s ...
fail("still rate limited after retries")

How to prevent 429 Too Many Requests

Rate limiting exists to protect you, yet a misconfigured limit can shut out real users and crawlers with no warning. Pulsetic checks your website from multiple locations every 30 seconds, at intervals gentle enough not to trip your limits, and alerts you by email, SMS, voice call, Slack, Discord, or webhook when a page starts returning 429 instead of loading. It watches availability from the outside, not your server's internals.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.