ChatGPT and OpenAI API outage triage: how to check, and what to do about it

Let a user confirm in under a minute that an OpenAI outage is not their account or device, and give a developer a correct failover and retry procedure instead of a reflexive retry loop.

Work Out Whether It Is Them Or You

ChatGPT and OpenAI API outage triage: how to check, and what to do about it

An ordered routine for when ChatGPT or the OpenAI API stops working: confirm whether the problem is OpenAI's or yours, read the error you are actually getting, and respond without making a recovering service worse.

0 of 17 done

Step 1 — Is it OpenAI, or is it you? (30 seconds)

Open OpenAI's official status page. It lists ChatGPT, the API and Codex separately, so check the one you are actually using — they do not always fail together, though on July 25 they did.status.openai.com ↗
Cross-check Downdetector. Official status pages routinely lag a live incident by minutes; a sudden spike in user reports is often the faster signal that the problem is not yours.Downdetector — OpenAI ↗
Try a second device on a different network — phone on mobile data, for instance. If it fails there too, the problem is upstream of you and nothing you change locally will help.
If it is a platform outage, stop troubleshooting. Do not reinstall the app, clear your account data, change your password or delete conversations. Nothing on your side is broken, and some of those steps cost you something permanently.

Step 2 — Read the error you are actually getting

A 503, or a page stuck loading the sidebar, points to the service being unavailable rather than to your request. During the July 25 outage users saw 503s carrying an internal circuit-breaker label — a signal that OpenAI's own systems were shedding load before requests reached the backend.
'Too many concurrent requests' during a known incident is usually load shedding, not you exceeding your own limit. Outside an incident, the same message really does mean your concurrency — check your usage dashboard before assuming otherwise.
A 429 is rate limiting or quota. If the status page is clean and only you are affected, check your organisation's limits and billing rather than waiting for an outage that is not happening.OpenAI API error codes ↗
A 401 or 403 is authentication or permissions — an expired, revoked or wrong-project API key. These never indicate an outage, and they will not resolve on their own no matter how long you wait.

Step 3 — If you are a developer, respond without making it worse

Retry with exponential backoff AND jitter, not on a fixed interval. Synchronised retries from thousands of clients are how a recovering service gets knocked over again — the jitter is the part people skip, and it is the part that matters.
Open a circuit breaker after a threshold of consecutive failures, and let it half-open before you resume. Hammering a dead endpoint burns your own capacity and slows everyone's recovery.
Queue what can wait. Non-interactive work — batch summarisation, enrichment, nightly jobs — should buffer and drain when service returns rather than failing user-visible requests alongside it.
Fail over only if you have already tested the fallback. A different provider or a smaller model returns different output, and swapping in an untested path during an incident replaces an outage with a correctness problem you cannot see.
Degrade visibly. Tell users the AI feature is temporarily unavailable rather than showing a spinner or, worse, silently returning nothing. A clear message costs you far less trust than an app that appears broken.
Check that retries are idempotent before you turn them up. If a retried call can double-charge a customer, send a duplicate message or write a record twice, aggressive retry logic turns an outage into a data problem that outlives it.

Step 4 — After it comes back

Do not trust the first success. Services recover in stages, and intermittent failures usually continue after the status page turns green — ramp traffic back up rather than restoring full load at once.
Read the incident history when it is published. It tells you which component failed, which is the only reliable input into whether your architecture needs a real fallback or just better retries.OpenAI status history ↗
Drain your queue and reconcile. Work that buffered during the incident needs to complete, and anything that failed mid-write needs checking — the quiet damage from an outage is usually inconsistent state, not the downtime itself.

How this is calculated

The order is diagnostic, not chronological: confirm scope from authoritative sources before touching anything you control, because a platform-wide outage and a local problem call for opposite responses. Error codes and symptoms listed are those reported during the July 25, 2026 outage and in OpenAI's published error documentation; each is mapped to what it indicates rather than to a guess at a cause. The developer section reflects standard resilience practice — exponential backoff with jitter, circuit breaking, idempotency — because retry behaviour during an incident is the one thing a caller fully controls. No live status is asserted anywhere; every status step points at a source that carries it in real time.

Data as of July 24, 2026 · verified July 24, 2026 · v1

Assumptions, limitations & sources

Assumptions

· The reader has working internet and the problem is specific to OpenAI's services.
· Developer steps assume a server-side integration where retry and failover logic is under your control.

Limitations

· This tells you how to check, not what the current status is. Live status comes from OpenAI's status page and user reports, not from this page.
· Error codes and their meanings can change between API versions. OpenAI's own error reference is the authority.
· Failing over to another model provider changes output characteristics — a fallback is a degradation, not a transparent swap, and needs its own testing.

Sources

OpenAI Status — official incident and uptime reporting — OpenAI, checked July 24, 2026
OpenAI API error codes reference — OpenAI, checked July 24, 2026
OpenAI confirms ChatGPT is down worldwide — BleepingComputer, checked July 24, 2026
OpenAI hit by another outage as ChatGPT, Codex and APIs go down together — The Next Web, checked July 24, 2026
Downdetector — OpenAI user-reported problems — Downdetector (Ookla), checked July 24, 2026

This tool accompanies our reporting — read the full story for context.

This is what modern SEO looks like: not just an article, but a useful resource people can return to, cite, and share. See how this newsroom is growing · See DavidWeaver's SEO packages

The story behind this tool

Technology

ChatGPT, the OpenAI API and Codex went down together — and it was not your account

OpenAI's services buckled worldwide early on July 25, with the company's own status page acknowledging elevated errors across ChatGPT, the developer API and Codex. Here is how to check whether it is them or you — and, if you build on the API, how to retry without making a recovering service worse.

DWC News

An independent news publication from DavidWeaver.codes. Published by David Weaver. Every story lists its sources; the newsroom doubles as a live, public SEO case study.

How this newsroom is growing →

Sections

Latest
U.S.
Politics
World
Business
Money
Technology
Science
Health
Entertainment
Sports
Search

The Newsroom

About DWC News
Editorial standards
Corrections
Authors
Contact the newsroom
RSS feed

Corrections: email hello@davidweaver.codes with the article link.