OpenAI Outage: Read 500 and 503 server_is_overloaded Correctly and Detect It in Your Logs

Failure facts checked on the vendor’s docs on Nov 8, 2026.

An OpenAI outage rarely means every call fails. More often one model is overloaded or slow while others work. If you read your errors as one number, a failing model hides inside healthy traffic. The details below come from OpenAI's own error and troubleshooting docs.

Errors that mean OpenAI is the problem

• 500: the server had an error processing the request. OpenAI says to retry after a brief wait and check its status page.
• 503 server_is_overloaded: type service_unavailable_error. The requested model is temporarily overloaded. Follow Retry-After when present, then retry, and lengthen the delay if it persists.
• Timeouts and dropped connections: these may be OpenAI or your own network path. OpenAI says client-side errors that never appear in its Service Health dashboard likely never reached it.

Errors that look like outages but are not

• 429 slow_down: your request rate rose too quickly. It can happen while you are inside your normal request and token limits.
• 429 credit_balance_exhausted, organization_spend_limit_exceeded, project_spend_limit_exceeded, organization_usage_limit_exceeded: OpenAI states that retrying billing, spend or quota errors will not restore access. Add credits or raise the limit.

Mixing these into an outage metric sends the on-call engineer to the wrong place. Classify by error.code, not only by HTTP status.

Example: one model degrading

This is an example, not output from a real project.

2026-11-08T13:05:10Z model=gpt-main status=200 ms=1840
2026-11-08T13:05:12Z model=gpt-main status=503 code=server_is_overloaded retry_after=4 ms=210
2026-11-08T13:05:13Z model=gpt-mini status=200 ms=620
2026-11-08T13:05:17Z model=gpt-main status=503 code=server_is_overloaded retry_after=8 ms=190
2026-11-08T13:05:19Z model=gpt-mini status=200 ms=590

Both models are called, and only one fails. Per-model grouping makes that obvious. A fallback to the second model, if your product can tolerate it, turns an outage into a quality dip.

A small classifier

NEEDS_HUMAN = {"credit_balance_exhausted", "organization_spend_limit_exceeded",
               "project_spend_limit_exceeded", "organization_usage_limit_exceeded"}

def kind(status, code):
    if code in NEEDS_HUMAN:
        return "billing_or_limit"
    if status == 429:
        return "rate_limited"  # includes slow_down: your traffic, not their outage
    if status in (500, 503) or code == "server_is_overloaded":
        return "provider_side"
    if status is None:
        return "network_or_timeout"
    return "other"

Log model, status, code, retry_after, attempt number and duration for every call, then count provider_side and network_or_timeout per model. Keep rate_limited out of that count: a 429, slow_down included, means your own traffic hit a limit.

Thresholds worth starting with

• Page when provider_side plus network_or_timeout is above 5% for one model over five minutes, with a minimum call count.
• Ticket, do not page, on any billing_or_limit event. It is a balance problem that will not fix itself.
• Watch latency alongside errors. OpenAI notes that latency analysis is most meaningful on tiers with defined SLAs, and standard tier can vary more.

Confirm with OpenAI

The OpenAI status page publishes incidents as JSON at status.openai.com/api/v2/incidents.json, with a status, an impact and timestamped updates, so you can show open incidents next to your own error rate. Enterprise API customers also get the Service Health dashboard. In it, filter to one model, one service tier and the affected project, open the HTTP Requests tab, and read error percentage rather than counts.

Outage or something on your side

Three quick checks separate the cases. First, compare models: if only one fails, the cause is almost always an overload on that model, not your code. Second, compare time: a failure that began exactly at a deploy points to a change in your request, such as a larger prompt or a new parameter. Third, compare paths: if requests from one network, proxy or region fail while another works, the problem is between you and the API. OpenAI's own guidance says to be precise about the model, tier and project before you report an issue, and to include example request and response timestamps.

During the incident

1. Respect Retry-After, and add jitter when it is missing.
2. Cap retries so a long outage does not turn into a retry storm.
3. Fail over to another model or a cached answer where the product allows.
4. Keep request timestamps for the vendor.

Checklist

• Calls are logged per model with status and error code.
• Billing and limit errors are separated from provider errors.
• Retries honor Retry-After and are capped.
• Status page incidents are visible next to your error rate.

Read vendor degradation detection for the method and third-party failure monitoring for the wider family of failures. For the cost side of model APIs, see LLM spend spikes. Sazabi can watch these per-model error shares and open an issue with the evidence.