Client Error

HTTP 429 Too Many Requests

The client has sent too many requests in a given time window — the canonical rate-limiting and abuse-protection status code.

Check a URL for HTTP 429

Paste any URL to see whether it currently returns 429. Runs a live HTTP probe and follows redirects.

TL;DR

A 429 means you're sending requests too fast — slow down. The fix is exponential backoff: when you see 429, wait the Retry-After value, then double the wait on each subsequent failure. Don't retry immediately in a tight loop; that's how you stay rate-limited forever. For server operators: include Retry-After in every 429 response.

What does HTTP 429 mean?

HTTP 429 Too Many Requests is what servers send when a client exceeds a rate limit. It's the polite way of saying "slow down" — and unlike 503 (which says "we're overloaded"), 429 specifically signals that this client has been quota'd, not that the server is in trouble. Well-behaved 429 responses include a Retry-After header telling the client exactly when to retry, plus optional rate-limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) that let clients self-pace before they hit the limit. APIs use 429 heavily; user-facing websites use it during attacks, brute-force login attempts, or scraper abuse.

Common Causes

•API client exceeded the documented rate limit (e.g. 60 requests/min)
•Login form hit by a brute-force attack — security plugin returns 429
•Aggressive web scraping detected by CDN bot management
•CI/CD pipeline hammering an API during a deploy
•Cloudflare or AWS WAF rate-limit rule triggered
•Misconfigured client lacking caching or retry backoff
•Shared IP (NAT, corporate proxy, mobile carrier) where one bad actor rate-limits everyone

How to Fix It

1.Implement exponential backoff: on the first 429, wait the Retry-After value; on the second, wait double; cap at a reasonable maximum
2.Read and respect the Retry-After header — most 429 responses include it as either seconds or an HTTP date
3.Cache API responses aggressively to reduce request volume — the cheapest way to stay under any rate limit
4.Read rate-limit hint headers (X-RateLimit-Remaining) and slow down proactively before hitting the limit
5.Move bursty work off the request path with a queue (Sidekiq, Bull, SQS) so a traffic spike doesn't become a 429 spike
6.Contact the API provider for a quota increase if your usage is legitimate
7.For server operators: always include Retry-After in 429 responses — without it, clients have no idea when to retry
8.For server operators: prefer 429 over 503 for per-client rate limiting — keeps the signals clean for Google

SEO Impact

If Googlebot receives 429, it interprets it as "back off and crawl less" — and it does, sometimes for weeks. A pattern of 429s in Search Console's crawl-stats report can reduce crawl rate sitewide, which slows indexing of new and updated pages. Use 503 with Retry-After for genuine overload (Google handles this gracefully); reserve 429 for actual abuse from specific clients. Whitelisting Googlebot, Bingbot, and other major crawlers in your rate-limit rules is best practice.

Monitor HTTP 429 with LemWatch

LemWatch respects rate limits when monitoring your sites — we use a low default check frequency and back off on 429. If you're seeing 429s in our logs, it usually means another monitoring tool (or a scraper) is hitting the same IP we are.

History & Context

HTTP 429 was introduced in RFC 6585 (2012) — a small RFC that added four "additional" status codes (428, 429, 431, 511) the original spec lacked. Before 429 existed, servers used 503 with a Retry-After for rate limiting, conflating "we're overloaded" with "this specific client is abusing us." 429 fixed the ambiguity. It is now the standard rate-limit response for every major API: GitHub, Stripe, Twitter/X, OpenAI, Cloudflare, AWS.

Real-World Examples

GitHub API

GitHub returns 429 with detailed rate-limit headers: X-RateLimit-Limit (your quota), X-RateLimit-Remaining (what's left), X-RateLimit-Reset (unix timestamp when the window resets). Authenticated requests get 5000/hour; unauthenticated get 60/hour.

Stripe API

Stripe returns 429 with a Retry-After header on rate-limited requests. Their docs explicitly recommend exponential backoff with jitter to avoid the "thundering herd" problem where every client retries simultaneously.

WordPress brute-force protection

Wordfence and Limit Login Attempts return 429 to IPs that exceed the failed-login threshold. Common cause of "I locked myself out of my own site" after a few mistyped passwords.

Exponential backoff with jitter — the right way to handle 429

javascript

async function fetchWithBackoff(url, options = {}, attempt = 0) {
  const MAX_ATTEMPTS = 6;
  const BASE_DELAY_MS = 1000;

  const res = await fetch(url, options);

  if (res.status !== 429 || attempt >= MAX_ATTEMPTS) return res;

  // Respect Retry-After if the server sent one.
  const retryAfter = res.headers.get('Retry-After');
  const serverDelayMs = retryAfter
    ? (isNaN(+retryAfter) ? new Date(retryAfter).getTime() - Date.now() : +retryAfter * 1000)
    : 0;

  // Exponential backoff with jitter: 1s, 2s, 4s, 8s, ... + random 0–500ms.
  const backoff = BASE_DELAY_MS * Math.pow(2, attempt) + Math.random() * 500;
  const delayMs = Math.max(serverDelayMs, backoff);

  await new Promise(r => setTimeout(r, delayMs));
  return fetchWithBackoff(url, options, attempt + 1);
}

Frequently Asked Questions about HTTP 429

What does HTTP 429 mean?

HTTP 429 Too Many Requests means the client has sent too many requests in a given time window and the server is rate-limiting them. It's different from 503 (which means the server itself is overloaded); 429 specifically signals that this client has exceeded its quota.

How do I fix HTTP 429 errors as a client?

Implement exponential backoff: on the first 429, wait the Retry-After value, then double the wait on each subsequent failure. Read rate-limit hint headers (X-RateLimit-Remaining) to slow down before hitting the limit. Cache responses to reduce request volume.

What is the Retry-After header?

A response header that tells the client how long to wait before retrying. It can be a number of seconds (Retry-After: 30) or an HTTP date (Retry-After: Wed, 21 Oct 2024 07:28:00 GMT). Well-behaved 429 responses always include it.

What is exponential backoff?

A retry strategy where the wait time doubles after each failure: 1s, 2s, 4s, 8s, 16s... It prevents the "thundering herd" problem where every client retries simultaneously after a rate limit lifts. Add a small random jitter (0–500ms) to prevent client retries from synchronising.

Why am I getting 429 errors when visiting a website?

Usually because security software detected your IP making too many requests — often a shared IP (corporate proxy, mobile carrier NAT) where someone else is the actual abuser. Fixes: switch networks, wait 15-60 minutes for the rate limit to clear, contact the site if blocked persistently.

What is the difference between 429 and 503?

429 means this specific client has exceeded its quota — slow down. 503 means the server itself is overloaded or in maintenance — try again later. 429 is per-client; 503 is server-wide. Google treats them differently: 429 reduces per-client crawl rate; 503 with Retry-After is honoured as planned maintenance.

How does 429 affect SEO?

If Googlebot receives 429, it reduces crawl rate sitewide — sometimes for weeks. Always whitelist major crawlers (Googlebot, Bingbot, DuckDuckBot) from rate-limit rules, and use 503 + Retry-After for genuine overload instead of 429.

What should a server include in a 429 response?

At minimum: a Retry-After header. Best practice also includes rate-limit hint headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) so well-behaved clients can self-pace. The response body should briefly explain the limit was exceeded and link to API docs.