Error guide

429 Too Many Requests

The client has been rate limited — the server is deliberately shedding its requests to protect itself.

A 429 means the client has sent too many requests and the server is refusing further ones for now. It is not a failure in the usual sense — the server is healthy and is deliberately protecting itself or enforcing a quota. A well-implemented 429 includes a Retry-After header saying how long to wait.

It is the most operationally interesting code in the 4xx class, because it is the only one that reliably says something about capacity rather than about correctness. A rising 429 rate against unchanged client behaviour means the limits are being hit by growth, or that limits were tightened, or that something is retrying far more aggressively than it used to.

In monitoring it has a particular trap: a monitor checking frequently can hit a rate limit by itself, especially when several monitors share an outbound IP with other traffic. The alert then describes the monitoring, not the service.

Common causes

  • Genuine traffic exceeding a configured rate limit or quota.
  • A retry loop without backoff amplifying a transient failure into a sustained one.
  • Monitoring checks at a short interval counting against the same limit as real traffic.
  • Rate limiting applied per IP where many clients share one address, so one noisy neighbour exhausts everyone's allowance.
  • An API quota — daily or monthly rather than per-second — that has been exhausted for the period.
  • A WAF or edge product rate limiting requests it classifies as automated.

How to diagnose it

  1. Read Retry-After and any X-RateLimit headers: they usually state the limit, the remaining allowance and the reset time.
  2. Establish which layer is limiting — the CDN, an API gateway, or the application — because each has its own configuration.
  3. Check whether the limit is per IP, per key or per account, which determines who is actually competing for it.
  4. Look for a retry storm: a client without backoff turns one slow response into hundreds of requests.
  5. If monitoring is implicated, lengthen the check interval or allowlist the monitor rather than removing the limit.

Whose fault is it? It depends which layer

The server is working as designed, so formally the client is at fault for exceeding the limit. But a 429 reaching real users is a capacity or configuration problem worth treating as a server-side incident.

What monitoring sees

Uptimely records the status code, so a 429 is visible for what it is rather than as an anonymous failure. If checks are themselves triggering the limit, the fix is a longer interval or an allowlist at the edge — a monitor whose alerts are caused by the monitor is the clearest possible source of alert fatigue.

Related error guides

Terms used on this page

Questions

Is a 429 downtime?

For the client receiving it, effectively yes — the request did not succeed. For the service it is working as designed. Whether it belongs on your status page depends on whether real users are hitting the limit or only automated clients are.

Can my uptime monitor cause 429s?

Yes, particularly at short intervals or where several monitors share an outbound IP with other traffic. Lengthen the interval or allowlist the monitor at the edge; do not remove the rate limit to make a check pass.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.