---
title: "429 Too Many Requests"
canonical: "https://lemwatch.com/http-status-codes/429"
category: "client-error"
last_verified: "2026-08-11"
source: "https://lemwatch.com"
---

# HTTP 429 Too Many Requests

**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 it 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

- 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.

**Related:** [403](https://lemwatch.com/http-status-codes/403.md), [503](https://lemwatch.com/http-status-codes/503.md), [408](https://lemwatch.com/http-status-codes/408.md)

_Canonical HTML page: https://lemwatch.com/http-status-codes/429_