downAPI errors and timeouts: distinguish outages, rate limits, and request failures
Use response codes, request IDs, timing, and product status to investigate API failures and avoid duplicate work.
Capture one failing request safely
Record the endpoint, HTTP status, timestamp, request ID, and elapsed time. Remove authorization headers, tokens, private prompts, and customer payloads before sharing diagnostic details.
Separate response categories
A 401 or 403 response commonly concerns access; 429 indicates a rate or quota restriction; 5xx responses indicate a server-side failure somewhere in the request path. These categories guide investigation but do not establish the cause or scope of an outage on their own. Check the provider’s error documentation.
Compare mapped incidents
Look for an incident affecting the actual API, model, region, or component you use. A working chat app or public homepage does not establish API availability. Compare the request time with the incident timeline rather than assuming a recent resolved incident explains a new error.
Retry without duplicating work
Follow the provider’s documented retry policy and Retry-After guidance. Use bounded backoff and idempotency where the API supports it. Before repeating a write, payment, or billable generation, determine whether the original request may already have succeeded.
Track recovery at the workflow level
A provider resolution marker is useful evidence, but verify your own application’s success rate and latency. Record whether the same failing request succeeds before changing unrelated credentials or redeploying a working integration.