---
title: 429 Too Many Requests
description: What HTTP 429 means, how Retry-After and rate-limit headers work, and how to build clients that back off correctly.
canonical: https://watchfor.io/docs/reference/http-status-codes/429
---

# 429 Too Many Requests

What HTTP 429 means, how Retry-After and rate-limit headers work, and how to build clients that back off correctly.

**429 Too Many Requests** means the client has exceeded a rate limit — too many
requests in a given window. The response should include a `Retry-After` header
saying when to try again, and often `RateLimit-*` /  `X-RateLimit-*` headers
describing the quota:

```
HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1767225600
```

## Common causes

- **A runaway loop** — a retry loop without backoff hammering an endpoint
  (which then rate-limits it, which triggers more retries…)
- **Shared IPs** — NAT, corporate proxies or serverless egress pools where many
  tenants share one IP and burn one IP-based quota
- **Fan-out on page load** — a frontend firing dozens of API calls per view
- **Batch jobs without pacing** — imports and syncs that blast an API at full
  speed instead of respecting documented limits
- **Scrapers and abuse** — in which case the 429 is your protection working

## Handling 429 correctly (client side)

1. **Honor `Retry-After`** — it's a number of seconds or an HTTP date; don't
   retry earlier.
2. **Exponential backoff with jitter** — when there's no `Retry-After`, back
   off exponentially and add randomness so a fleet of clients doesn't
   synchronise into waves.
3. **Never retry 429 immediately** — that converts a rate limit into an outage.
4. **Watch the remaining-quota headers** and slow down *before* hitting zero.

## Handling it server side

Rate limits protect capacity, but a growing background rate of 429s to
legitimate users means limits are tuned too low or clients are misbehaving —
either way you want to see the trend, not discover it from complaints.

## Debugging

Reproduce with the free [API tester](/api-tester) and read the rate-limit
headers to see the actual quota and window. When monitoring endpoints that are
themselves rate-limited, check the interval math: a monitor every 30 seconds
consumes ~2,880 requests/day against your quota — schedule accordingly, or
monitor a dedicated health endpoint excluded from limits.

---

Canonical page: https://watchfor.io/docs/reference/http-status-codes/429 · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt