Identify the limit actually reached
HTTP 429 indicates too many requests and may include Retry-After. Counting and scope remain service-specific. A low average does not prevent a burst from exceeding a short-window limit.
| Concept | What it bounds | Useful action |
|---|---|---|
| Quota | Volume over a period | Plan the shared allowance. |
| Rate | Arrivals within a short window | Spread request starts. |
| Concurrency | Operations in progress | Cap simultaneous work. |
| Retry-After: 120 | Wait for 120 seconds | Check the overall deadline and retry safety. |
Schedule authorized demand
- Check the accounting key: account, project, user, route or another scope. Verify reset timezone, operation costs and sharing between applications.
- Smooth bursts through a bounded queue and separately limit in-flight operations. Propagate cancellations and discard work that is no longer useful.
- Interpret Retry-After as an HTTP date or a delay in seconds. Respect it within a time budget; define bounded waiting when it is absent.
Assess retries without bypassing protection
A 429 response does not prove an operation can safely be repeated. Check idempotency, overall time and attempt limits. Measure rejections and queue length; if sustained demand exceeds the contract, reduce demand or agree suitable capacity.
Primary references
Make rate-limit abuse observable
Request limits work better when they distinguish legitimate use from abnormal behavior and produce an interpretable event. Error codes alone may hide an abuse pattern’s start, duration and reach.
- Record threshold, decision, route and minimal context without secrets.
- Correlate repeated denials with effects on legitimate users.
- Test that alerts lead to investigation or proportionate tuning.
Primary reference: ACSC and partners — Event logging and threat detection. Related method: read the practical guide.