HTTP 429 Too Many Requests

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…

What 429 means

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

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

Monitoring tip

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.

Background

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.

Frequently asked questions

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.