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

OpenAI's services failed worldwide on the morning of Saturday, July 25, 2026. Reporting puts the start at roughly 5 a.m. Eastern, and it took down three products at once: ChatGPT, the developer API and Codex.

If you spent part of that morning wondering whether you had been rate-limited, logged out, or somehow broken your own account: you had not. Nothing on your side caused it, and nothing on your side would have fixed it.

Outages end. The skill of telling a platform failure apart from a local one does not, so this piece leads with that — and with the part written for the people who build on the API, where the wrong reaction genuinely makes things worse.

What happened

Users hit a recognisable set of symptoms. Chats stuck on loading animations, with the sidebar never populating and conversation history apparently missing. Messages that would not send, returning "too many concurrent requests." And 503 errors carrying an internal label pointing at an open circuit breaker — a system deliberately refusing requests before they reach the backend.

That last detail is the informative one. A circuit breaker tripping is not a crash; it is a service shedding load on purpose to protect itself. It tells you the failure was upstream of the models and that OpenAI's systems were doing what they were designed to do under stress.

OpenAI's status page acknowledged elevated error rates across ChatGPT, the API and Codex. The company moved the incident from investigating to monitoring within about an hour, saying it had applied a mitigation — at which point it had not identified a cause publicly or offered a recovery estimate.

What we are not going to tell you is why it happened. As of this writing, no root cause has been published. Posts confidently attributing it to a specific provider, a deploy, or a traffic surge are guessing, and the incident history OpenAI publishes afterward is the thing worth waiting for.

The 60-second version: is it them or you?

Three checks, in this order:

1. status.openai.com — the official page, which lists ChatGPT, the API and Codex separately. Check the one you are using.
2. Downdetector — the crowd usually knows first. Official status pages lag live incidents by minutes, routinely.
3. A second device on a different network. If your phone fails on mobile data too, the problem is upstream and local changes will not help.

Then the step people skip: stop troubleshooting. During a platform outage, do not reinstall the app, clear account data, change your password, or delete conversations. Some of those are irreversible, and none of them are the problem.

The checklist below covers this and the developer half in order.

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 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

For developers: the retry that makes it worse

If you build on the API, an outage hands you exactly one decision you fully control — how you retry — and the instinctive answer is the wrong one.

Retry with exponential backoff and jitter. The backoff part is well known; the jitter is the part that gets dropped, and it is the part that matters. Without random spread, every client that failed at the same moment retries at the same moment, and a service that is halfway back up gets knocked over by a synchronised stampede. You are not just protecting yourself. You are part of everyone else's recovery.

Open a circuit breaker. After a threshold of consecutive failures, stop calling and half-open later to test. Hammering a dead endpoint burns your own capacity for no return.

Check that your 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 converts a temporary outage into a data problem that outlives it by weeks. This is the failure that actually costs people money, and it shows up in the reconciliation, not in the incident.

Fail over only to something you have tested. A different provider or a smaller model does not return the same output. Swapping in an untested path mid-incident trades an outage you can see for a correctness problem you cannot.

And degrade visibly. Tell users the AI feature is temporarily unavailable. A clear message costs far less trust than a spinner that never resolves.

The dependency question this keeps raising

Three products failing together is worth sitting with. ChatGPT, the API and Codex are different surfaces on shared infrastructure, and when the shared layer goes, having "another OpenAI product" is not a fallback.

That is the uncomfortable arithmetic of the current AI stack. An enormous amount of software now has a single vendor on its critical path for a user-facing feature, and most of it has no tested alternative. The honest response is not panic — it is deciding, in advance and in daylight, which features must degrade gracefully and which can simply be unavailable for a few hours.

Most teams have never made that decision explicitly. They discover it during an outage, at 5 a.m.

The questions readers are asking

Is ChatGPT down right now? This page cannot tell you — it is not live status. Check status.openai.com and Downdetector, in that order.

Was it my account? No. This was a global, multi-product outage.

Did I lose my conversation history? Chats appearing to vanish was a symptom of the sidebar failing to load, not of data being deleted. History returning with the service is the expected outcome.

What does "too many concurrent requests" mean? During a known incident, load shedding. Outside one, it means you actually are exceeding your concurrency — check your usage dashboard before assuming the platform is at fault.

What caused it? Not published. OpenAI applied a mitigation without naming a cause. Wait for the incident history.

Will I be compensated? Consumer subscriptions generally do not refund for outages. API customers should read their own service agreement — enterprise contracts sometimes carry service credits, consumer plans do not.

Does this happen often? OpenAI has had multiple notable outages, and reporting framed this one as "another." That is a reason to build for it, not a reason to be surprised by it.

Should I switch providers? Switching to a single different vendor swaps one dependency for another. The useful move is a tested fallback path and features that degrade well — not loyalty to a different logo.

What to watch

The incident history. When OpenAI publishes what actually failed, that tells you whether this was a shared component that will take all three products down again — which is an architecture question for everyone who builds on it — or something narrower.

Until then, the honest status is the one on the status page, refreshed. Not this article.