ChatGPT down? How to tell if it's OpenAI, your network, or your account

Is ChatGPT down right now, or is it just you?

ChatGPT fails in a way that looks identical whether the problem is OpenAI's or yours: a spinner, a red error, a conversation that will not load. Before you clear cookies or reinstall anything, spend a minute establishing which side is broken.

If the status page is green and a second account on a different network also fails, treat it as an unacknowledged incident and wait. If the second account works, the problem is yours — usually session, extension, or network.

Why status.openai.com can say 'operational' while ChatGPT is broken

Status pages are published by humans reacting to monitoring, so they trail reality by design. On 4 February 2026, users were hitting failed conversations and 403 errors while the OpenAI status page still listed every component as fully operational; the acknowledgement came after Downdetector reports had already peaked above 15,000. The same lag showed up again in the outages later that year.

Three things follow from that, and they are worth knowing before you are in the middle of one:

• Green does not mean working. A green page during a report spike means "not yet acknowledged", not "your fault". Stop debugging your own setup once the crowd signal is unambiguous.
• Read components, not the headline. The status page tracks ChatGPT, the API, Sora and Codex separately, and incidents are often scoped even more narrowly than that — the 1 September 2026 entry, for instance, was elevated errors in ChatGPT conversations specifically for Free and Go plans. A partial outage that misses your plan tier is invisible in the summary.
• The incident history is the useful artefact. The status history is where you find whether this is the third incident this week and whether the last one lasted 50 minutes or 10 hours. That is the number you need when deciding whether to wait or fail over.

Microsoft's status pages behave the same way, for the same structural reasons — we walk through that in detail in our piece on diagnosing an Outlook outage.

ChatGPT can be down while the API is fine, and the reverse

This is the most useful thing to understand about OpenAI outages, and most coverage misses it. The consumer app, the authentication layer and the API are separate surfaces that fail independently.

Two practical consequences. If you are a user and ChatGPT is down, a project running against the API may be completely unaffected — check before you assume your build is blocked. And if you are a developer, your users reporting "ChatGPT is down" tells you almost nothing about your own integration. Monitor the API surface you actually call, not the consumer app your users read about on X.

The cheapest possible check, which takes seconds and is worth keeping in a note:

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
  https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY"

A 200 means the platform is serving you. A 401 is your key. A 429 is your quota or rate limit. A 500, 502 or 503 is theirs.

What ChatGPT and OpenAI API errors actually mean

The error code tells you whether waiting will help. This matters because the wrong response — retrying an error that will never succeed, or giving up on one that would have — is what turns a short incident into a long one.

Two details from OpenAI's own guidance that developers routinely get wrong. First, on a 429, OpenAI's rate-limit guidance says to honour the Retry-After header when present and otherwise use exponential backoff with jitter, bounding both the retry count and the total time spent retrying. Second, failed requests still count against your per-minute limits, so a tight retry loop during a rate-limit event actively prolongs it.

The other one worth knowing: the official SDKs already retry eligible errors. If you wrap them in your own retry loop without accounting for that, your effective retry count is the product of the two, not the sum. That is how a 3-retry policy quietly becomes 9 requests against an already-struggling endpoint.

How long ChatGPT outages usually last

Short, mostly. The distribution matters more than the average, because it tells you whether the right move is to wait or to fail over.

So: most incidents resolve inside an hour, and roughly once a year one does not. That shape is what your retry and fallback policy should be tuned to. Retrying for 60 seconds handles the common case. Nothing you can do with retries handles a 10-hour outage — that needs a different provider or a degraded mode.

What to do while ChatGPT is down

• Do not reset your password. If the incident touches authentication, a reset during the outage can leave you locked out after recovery. Wait.
• Try the other surfaces. Mobile app, desktop app and web hit different paths, and incidents are often scoped to one of them.
• Check your plan tier against the incident. Several 2026 incidents were scoped to specific plans or to work accounts. If the status entry names a tier that is not yours, keep debugging locally.
• Do not paste work into an unvetted alternative. The reflex during an outage is to grab whatever chatbot loads. If your organisation has rules about what can go into which AI tool, an outage is exactly when they get broken.
• If you are mid-task, save your prompt locally. Conversations that fail to load during an incident usually come back, but drafts typed into a broken session do not.

How to build on the OpenAI API so an outage does not take you down

If your product calls an LLM in the request path, your uptime is capped by your provider's. The goal is not to eliminate that dependency, it is to make an incident degrade your product instead of stopping it.

Five layers, in the order they pay off:

1. Bounded retries with jittered backoff. Retry only 429, 500, 502, 503 and connection failures. Cap total retry time at something like 30–60 seconds, which covers the median incident, and never retry 400, 401, 403 or exhausted quota.
2. An aggressive timeout. Latency-based degradation is more common than hard failure. A request that hangs for 120 seconds holds a worker and cascades into your own outage. Set a timeout tied to your product's tolerance, not to the SDK default.
3. A circuit breaker. After N consecutive failures, stop calling for a cooling-off period. Without one, every request in flight queues against a dead endpoint and your own service falls over before the provider recovers.
4. A fallback path. Either a second provider behind the same interface, or a degraded mode — a cached answer, a smaller model, a template, or an honest "AI features are temporarily unavailable" that keeps the rest of the product usable. Decide which per feature: a support-ticket summariser can wait, a checkout flow cannot.
5. Queue anything that is not user-facing. Batch classification, enrichment, summarisation and report generation have no business failing during a 40-minute incident. Persist the job, drain it later.

The shape of the client code, stripped to the decision logic:

RETRYABLE = {429, 500, 502, 503}

def call_llm(payload, deadline_s=45):
    started = time.monotonic()
    delay = 1.0
    while True:
        try:
            return primary.create(**payload, timeout=20)
        except APIStatusError as e:
            if e.status_code not in RETRYABLE:
                raise                      # your bug, not theirs
            if time.monotonic() - started > deadline_s:
                break                      # stop; this is an incident
            retry_after = e.response.headers.get("retry-after")
            sleep = float(retry_after) if retry_after else delay
            time.sleep(sleep + random.uniform(0, 0.5))   # jitter
            delay = min(delay * 2, 16)
    breaker.open()                         # stop hammering a dead endpoint
    return fallback(payload)               # other provider, cache, or degrade

Note what the deadline does: it converts an open-ended outage into a bounded, predictable failure your product can handle. That single change — a hard deadline plus a defined fallback — is usually the difference between an incident your users notice and one they do not. Getting this right across a whole application is the unglamorous half of building AI features that run in production rather than in a demo.

The ten-minute resilience check

Whether or not ChatGPT is down as you read this, these five questions take ten minutes and will tell you how your next outage goes. Every "no" is a place where a provider incident becomes your incident.

1. Do you have a timeout on every LLM call, set deliberately rather than inherited from the SDK default?
2. Do your retries distinguish retryable from non-retryable errors, and do they have a total deadline?
3. Does a provider failure return a usable degraded response, or a stack trace?
4. Do you alert on a rising error rate, or do you find out from a user?
5. Is there any non-user-facing LLM work still running synchronously that could be queued?

Most teams answer no to at least three, usually because the AI feature shipped fast and the error handling was left for later. It is a few days of work to close, and it is much cheaper before an incident than during one. Send us the shape of your setup and we will point at the weakest link.