What Is a 429 Too Many Requests? Hitting a Rate Limit
A 429 Too Many Requests is the HTTP status a server returns when a client has sent more requests than the rate limit allows and must wait before trying again.
Unlike most 4xx errors, a 429 does not mean your request was malformed; it means you sent too many, too fast. Pipelines that fan out across many jobs or poll APIs aggressively hit 429s often. The right response is to back off and retry, ideally guided by the server hints in the response.
A rate-limit signal
The server returns 429 when you exceed its allowed request rate for your token, IP, or account. It is the explicit way an API says "slow down" rather than failing silently.
Read the headers
- Retry-After tells you how long to wait.
- Rate-limit headers report remaining quota and reset time.
- Honoring these is the correct, polite way to back off.
Why CI hits 429s
A matrix build, parallel jobs sharing a token, or a tight polling loop can blow through a quota quickly. Concentrating many calls in a short burst is the usual culprit.
Backing off correctly
Use exponential backoff with jitter so retries spread out instead of all retrying at once. Add caching and trim unnecessary calls to stay under the limit in the first place.
Retryable, with a wait
A 429 is one of the few client-side codes that is meant to be retried, but only after the indicated delay. Retrying immediately just earns another 429 and can extend the penalty.
Automatic backoff on runners
Robust tooling detects 429s and retries after honoring Retry-After. Latchkey runners back off and retry transient 429s from common endpoints so brief throttling does not fail an otherwise healthy job.
Key takeaways
- A 429 means you exceeded a rate limit and should wait before retrying.
- Honor Retry-After and rate-limit headers instead of retrying immediately.
- It is retryable after a delay, unlike most other 4xx errors.