Handling 429 rate limits
Bound concurrency, honor retry instructions, and avoid retry storms.
FetchGauge technical notes · examples run only when you execute them
Respect the rate limit
A 429 response indicates too many requests. If present, follow the Retry-After response header; it can specify a delay or a date.
Use a bounded queue
Limit concurrent work and keep a retry budget. Back off after failures and stop after the budget is exhausted. Record original attempts and retries separately to expose their cost.
Measure useful work
Report successful documents alongside attempted requests. A high request count can hide repeated work and increasing latency.
References
Compare with context
FetchGauge’s current benchmark data is simulated. Use the methodology to understand the intended protocol, and the calculator to explore its cost assumptions.