Server
HTTP 429
Also called Too Many Requests.
HTTP 429 is the status code for 'Too Many Requests': the client sent more than the server will accept in a given window. A good server adds a Retry-After header saying when to try again.
How it is measured
Count 429 responses per client key, IP or token over a window, and compare to the configured limit. Look at the Retry-After value and any RateLimit-Remaining headers to see how much headroom a client had.
On a monitor, a 429 to your own probe means the probe is being limited, so check whether a WAF or CDN is treating the monitor as a bot before assuming the site is down.
Worked example
A REST API allows 60 requests per minute per key. A reporting script pulls 900 orders with one call each and gets 429 from request 61 onward, with Retry-After: 38. A script that ignores the header and retries instantly sends 400 more calls in a minute, all rejected.
After adding a sleep that honours Retry-After and fetching 100 orders per call, the job finishes in 9 requests and zero rejections.
How it differs
HTTP 429 says the caller is going too fast, so slow down. HTTP 503 says the server cannot handle the request right now whoever is asking. A 429 excludes server-wide trouble and targets one client, while 503 excludes a per-client quota and describes the whole service. The retry advice differs: back off on 429, wait for recovery on 503.
Common errors
Retrying immediately without backoff. Ignoring the Retry-After header. Counting 429 as a server error in uptime reports. Limiting by IP when many users share one NAT. Returning 403 or 200 with an error body for rate limits, which hides the signal from clients.
In practice
Check your access logs for 429 counts by path this week. Make sure every limit returns Retry-After, whitelist your uptime checker, and let clients see how much quota is left in a header.