ChatGPT's outage took Codex and the API down with it

At around 5 AM Eastern on July 25, ChatGPT stopped answering. So did Codex. So did a dozen API endpoints. If you have a support bot, a document pipeline, or a checkout assistant that calls OpenAI and waits for the reply, your product was down for the same hour — and your customers had no way to tell the difference between your bug and someone else's. The ChatGPT outage is a small event with a large lesson about how you wire model calls.

What actually happened

Per BleepingComputer, users worldwide hit "too many concurrent requests" errors and hung loading states starting around 5 AM ET. OpenAI acknowledged the incident on its status page at 5:30 AM ET, listing ChatGPT, Codex, and twelve API components as affected, and service came back roughly an hour after it started. In outage terms, unremarkable. Nothing was lost, nothing leaked.

The useful number isn't the duration — it's the baseline. OpenAI's own status page reports aggregate uptime from April through July 2026 of 99.93% for the APIs, 99.67% for ChatGPT, and 99.98% for Codex. Take the API figure at face value: 99.93% is about 30 minutes of unavailability a month. The ChatGPT figure works out closer to two and a half hours. Those are honest numbers for infrastructure under this much load, and they are also nowhere near the availability most people quietly assume when they drop a client.messages.create() call into a request handler.

Why model API uptime matters for your business

The failure mode that hurts isn't the model being down. It's your architecture treating a third-party network call as if it were a local function. A synchronous call to any provider, inside a request the customer is waiting on, with no timeout and no alternative, converts every one of their incidents into one of yours — plus your support inbox, because the error your customer sees is your logo.

Three patterns fix it, in order of effort. Set an aggressive timeout and degrade to something useful: a form, a queue position, a human handoff. "We'll have an answer to you in a few minutes" is a fine outcome; a spinner that never resolves is not. Second, move anything that isn't conversational off the request path entirely — summarization, categorization, enrichment, and product-description generation belong in a job queue with retries and backoff, where a one-hour provider outage costs you a one-hour delay and nothing else. Third, put your model calls behind one internal interface with the provider in config, so a second route is a deploy and not a rewrite. We've argued for that abstraction here before on cost and portability grounds. Uptime is the third reason, and it's the one your customers actually notice.

Sources: BleepingComputer, OpenAI Status.