Investigating API rate limits without creating a retry storm

When an API starts rejecting requests, retries can leave unrelated work waiting behind them. Check the applicable limit and the work each retry adds to your application.

Establish the scope

Record the operation, response code, time, and any limit information returned by the API. Check your account’s applicable limits and recent changes in request volume. A rate-limit response from one account does not by itself establish a provider-wide incident.

Review the provider’s status report separately from your own request data. Keep both in the incident timeline, with their sources, rather than treating them as interchangeable evidence.

Inspect retries and concurrency

Find every layer that can retry the same operation: the client library, application code, job runner, and queue. Check whether their combined behaviour creates more work while the original requests are still waiting.

Set retry and concurrency policies for the operation you are running. Account for the provider’s guidance, how long the caller can wait, and whether repeating the operation can cause a side effect. Test cancellation and failure paths as well as recovery.

Check what shares the queue

Identify work that shares workers, connections, or concurrency limits with the affected integration. If a background AI job can delay a payment callback or another critical task, review that dependency explicitly.

After changing the retry policy, check whether accepted requests are completing and the backlog is shrinking. Keep the original request, retries and final outcome together so repeated attempts are not counted as separate jobs.

Correction, September 6, 2026: removed an unsupported incident timeline and detection lead-time figures. This is an investigation guide.