Rate Limit & Quota Exhaustion Playbook

During a rate-limit incident, the objective is not to retry harder. It is to preserve remaining quota for the highest-value traffic and stop unnecessary request generation.

Trigger / symptom

HTTP 429 or provider limit errors rise, remaining quota falls rapidly, scheduled jobs compete with user traffic, or the supplier applies throttling latency.

Inputs needed

Know the limit window/reset time, whether limits are global or credential-scoped, endpoint cost, remaining quota, current RPS, retry-after information and background-versus-interactive traffic mix.

Ordered response

1. Confirm the provider's limit contract.
2. Respect retry-after/reset headers.
3. Cap automatic retries.
4. Slow or pause background crawl/refresh jobs.
5. Prioritize interactive booking-intent requests.
6. Increase effective cache use and coalesce duplicate requests.
7. Apply token-bucket or leaky-bucket shaping locally.
8. Do not shard credentials to bypass contractual limits unless explicitly permitted.

Decision tree

If normal traffic exceeds the limit, capacity planning is wrong.

If the event is a sudden spike, find duplicate loops or bot traffic.

If background jobs dominate usage, change schedule and batch size.

If the provider appears to enforce an incorrect limit, escalate with request IDs and counters.

Stop conditions

429 rate returns to baseline, quota remains at a safe level and backlog drains in a controlled way.

Metrics proving resolution

Track 429 rate, quota burn rate, cache hit, request-coalescing ratio, queued-work age and successful requests per quota unit.

Prevention

Build a quota-budget dashboard and allocate separate budgets/priorities for user-facing and scheduled/background workloads.