ChatGPT's Outage Streak: 4 Failures in 4 Days

On Saturday, July 25, ChatGPT, the OpenAI API, and Codex all went down at once, worldwide. Users couldn't load chat history, developers got 503s from the API, and it was OpenAI's fourth service disruption in four days. Here's what actually happened, why it kept repeating, and how to design a system that depends on an LLM provider so it survives this class of failure.

What actually happened on July 25?

OpenAI's status page confirmed elevated error rates across ChatGPT, the developer API, and the Codex coding assistant starting that morning. Users worldwide couldn't log in, load saved conversations, or send messages — many saw a sidebar stuck in an infinite loading spinner, with background requests failing on "too many concurrent requests" errors. It wasn't just the ChatGPT interface: the API endpoints that thousands of third-party applications depend on were affected at the same time, which points to a shared infrastructure layer rather than an isolated front-end bug.

This wasn't a one-off. OpenAI's own status history shows elevated error rates in ChatGPT and API image generation on the Wednesday of that same week, then separate degradations in the general API and in Codex Review on Thursday. Saturday's global outage was the fourth service disruption in that same four-day window — a pattern, not an isolated accident.

What does "biscuit_baker_service_me_circuit_open" tell us?

Most of the 503 errors developers saw during the outage carried an internal label: biscuit_baker_service_me_circuit_open. The name reads like an inside joke, but it's technically informative — "circuit open" means a circuit breaker tripped, rejecting requests before they reached a degraded backend service. So the failure itself likely wasn't a broken circuit breaker; it was a protective mechanism correctly opening in response to a real degradation somewhere upstream. The open question is what was actually failing behind that circuit — OpenAI hasn't published a public root-cause breakdown.

OpenAI moved from "investigating" to "monitoring" within about an hour, saying it had applied a mitigation and was watching for recovery. Services eventually came back, but a detailed postmortem still hasn't been published, which makes it hard for developers to judge whether the same failure class will recur.

This is part of a pattern

The more notable fact isn't the single outage — it's the frequency. OpenAI's status-page history shows roughly 166 incidents logged over about nine months since autumn 2025, an average of around 18 per month. Most of those are partial degradations or regional blips, not full global outages like July 25's. But a four-day window with four separate disruptions signals that these events are no longer rare exceptions — they're a regular background condition anyone running production on top of the API now has to plan around.

This isn't unique to OpenAI — it's the natural risk profile of any GPU-constrained service scaling this fast. But the practical consequence is the same either way: if you have a feature built on ChatGPT or the OpenAI API, "the provider will always be up" is no longer a safe assumption.

What was the real developer impact?

Codex being affected pushes this past an ordinary consumer-product outage: teams generating code or automating CI steps through Codex were fully blocked during that window. On the API side, the "too many concurrent requests" error suggests something closer to a degradation in the auth or request-routing layer than a simple capacity ceiling — normal rate limiting usually shows up as gradual throttling, not a sudden, bulk error spike.

The practical takeaway: if you have a production workflow synchronously and unforgivingly wired to a single provider's API, you can expect a window like this roughly once every few days right now. As our post on rate limiting: token bucket vs sliding window covers, even disciplined rate limiting on your own side won't save you if the counterparty is the one that's down — the real question is how your system behaves when a dependency is degraded, not healthy.

Designing LLM integrations that survive this

The good news is that resilience patterns for this class of failure are well-established; they just need to be applied to LLM APIs specifically.

async function callWithResilience(prompt: string) {
  try {
    return await circuitBreaker.fire(() => primaryProvider.complete(prompt))
  } catch (err) {
    if (circuitBreaker.opened) {
      return await fallbackProvider.complete(prompt) // a different provider
    }
    throw err
  }
}

As our guide on retries, backoff, and circuit breakers details, you need a circuit breaker on your own side too: when a provider degrades, stop hammering it and reroute traffic to a fallback path — a different model or a different provider — instead of retrying blindly. Retries themselves should be bounded with exponential backoff, or you end up adding request pressure to a service that's already struggling.

The second critical piece is idempotency: you need to be able to safely resend a request without a duplicate execution causing side effects. The principles in our idempotent API design guide apply directly to LLM calls too — especially when a tool call triggers a payment or an email send, you need a way to check whether the request already completed before retrying it. Our LLM guardrails checklist for production covers this class of failure scenario as part of a broader production checklist for agents.

The third option is a multi-provider architecture: designing a critical flow so ChatGPT is primary but Claude or Gemini serves as a fallback rather than a single point of failure. Our Gemini vs ChatGPT comparison covers API-level behavioral differences that matter directly when picking a fallback provider, and we covered a similar diversity argument for voice assistants in our AI voice assistants compared post.

My take: single-provider dependence is now a risk-management mistake

Honestly, this incident crystallized something for me: in 2024, "which model is better" was a reasonable priority to debate. By 2026, the real question for production systems has to be "what happens when the provider goes down." Depending on a service that's averaging 18 incidents a month, with no fallback plan, isn't that different from deploying to a single cloud region with no redundancy — the industry already learned that lesson on cloud infrastructure. It hasn't fully learned it yet on LLM APIs.

Frequently Asked Questions

Did OpenAI explain the root cause of the outage?

No, a detailed public root-cause analysis hasn't been published as of this writing. OpenAI announced it moved from investigating to monitoring and applied a mitigation, but the technical detail behind the biscuit_baker_service_me_circuit_open label hasn't been shared.

How often do outages like this happen?

Based on OpenAI's status-page history, roughly 166 incidents have been logged over about nine months since autumn 2025 — an average of around 18 per month. Most are partial or regional, but fully global outages like July 25's recur less often, though still regularly.

I have a production system that depends on the ChatGPT API — what should I do?

At minimum, add a circuit breaker and bounded exponential-backoff retries for critical flows. Where possible, build an abstraction layer that can fail over to a second provider (Claude, Gemini), and make sure every tool call is idempotent so a retry during an outage doesn't cause duplicate side effects.

Is this an OpenAI-specific problem?

No — every AI provider operating at this scale carries similar risk. What's distinct here is that OpenAI's status page makes these incidents visible, and four in a row over four days drew attention. The same discipline (fallback paths, circuit breakers, monitoring) applies regardless of which provider you build on.