OpenAI ChatGPT outage June 2025 — an illustrative AI-capacity story

On June 10, 2025, ChatGPT and OpenAI’s API went down for more than ten hours. Free users, Plus subscribers, API customers, and Sora users were all affected as approximately 21 service components reported failures simultaneously. OpenAI resolved the incident by addressing what it called “the underlying infrastructure issue,” but no detailed root-cause analysis was published.

Important: the load cause discussed in this post is inferred, not confirmed. This incident is included here as an illustrative story about how AI inference capacity pressure can manifest — not as a case where a verified load root cause is documented. Where causation is uncertain, this post says so plainly.

What happened

According to contemporaneous reporting, the outage began on June 10, 2025 and lasted more than 10 hours. Users reported that ChatGPT was entirely unavailable or returning errors, and the OpenAI API was similarly affected. The scope — free tier, paid Plus tier, API access, and Sora all failing at once — indicated a platform-level failure rather than a front-end or isolated service problem.

OpenAI’s public communications acknowledged the incident and stated that the infrastructure issue was fixed. The CEO referenced heavy demand on the system in broader public comments around this period, though not as a direct explanation of this specific incident. No formal postmortem was released.

Given the scope, the duration, and the context of rapidly growing usage at the time, load and capacity pressure on AI inference infrastructure is a plausible contributing factor — but it remains inferred.

The timeline

• June 10, 2025: Extended outage begins; free, Plus, API, and Sora services unavailable or degraded.
• ~21 components reporting failures: Status page shows broad simultaneous impact, suggesting a shared infrastructure layer rather than an isolated service.
• 10+ hours of degradation: Extended duration before resolution, suggesting the fix required more than a simple restart or configuration rollback.
• Resolution: OpenAI engineers address the underlying infrastructure issue; services restore.
• No public postmortem: No detailed root-cause analysis published as of this writing.

Why it happened

Without an official postmortem, this section is necessarily speculative and is offered as an illustrative analysis rather than a verified account.

AI inference workloads place unusual demands on infrastructure. Unlike traditional API requests that complete in milliseconds, inference requests are computationally intensive, time-consuming, and stateful in ways that make horizontal scaling more complex than simply adding servers. GPU resources are expensive, provisioning them is slow, and the demand for AI services grew faster in 2025 than most capacity planning cycles could accommodate.

If capacity pressure was a contributing factor here, the likely dynamics would include: inference requests taking longer under heavy load, queues backing up, and a feedback loop where delayed responses caused clients to retry — increasing load further. At some point, the system would be unable to serve new requests at all, explaining the broad component failures observed.

Again: this is the inferred pattern, not the confirmed cause. Teams building on AI inference APIs should use this as motivation to test for capacity boundaries, not as a statement about what OpenAI’s internal postmortem would have found.

The failure pattern

This incident is classified as a capacity-ceiling failure in the AI/GPU pool sub-type. The pattern is relevant to any team building on top of AI inference infrastructure — either a third-party provider or a self-hosted model serving system.

AI inference has a property that makes capacity ceiling failures particularly impactful: inference requests are often synchronous and user-visible. When a web search or database query fails, the user sees an error. When an inference request fails, the user’s workflow stops. The downstream impact of inference unavailability is usually more visible and more disruptive than equivalent downtime in supporting services.

Teams that build applications on top of AI inference APIs need to understand: what does your application do when the inference provider returns a 429 or 529? Does it queue gracefully, show a meaningful message, and retry with backoff — or does it surface a confusing error to the user?

How it could have been prevented

The following is framed as general engineering practice, not as a claim about what OpenAI should have done differently.

Provision inference capacity ahead of demand signals. GPU and accelerator provisioning lead times are long. Teams that wait until utilization metrics show saturation before ordering more capacity will always be behind the demand curve. Capacity planning for AI infrastructure needs to operate on demand forecasts, not current utilization.

Implement graceful load shedding before the ceiling. A well-designed AI service begins returning 429 or 529 responses before it reaches total unavailability. A system that sheds load gracefully — accepting some requests and declining others with a clear retry-after signal — is far more resilient than one that attempts to accept everything until it falls over.

Build client-side retry logic with backoff. Applications calling AI inference APIs should assume that 429 responses will occur and handle them with exponential backoff and jitter, not immediate retry. A client that retries immediately on a 429 makes the capacity problem worse.

Test your application’s behavior under inference-provider degradation. The most actionable question is not “will the provider stay up?” — it is “when the provider is slow or shedding load, how does my application behave?”

How to test for this with MaxoPerf

If you operate your own AI inference infrastructure, or if you want to understand your application’s resilience when the inference API it depends on is under pressure, there are two distinct tests worth running.

Test 1 — Breakpoint test on your inference endpoint

If you host or control your own model-serving infrastructure, run a breakpoint test against your inference endpoint using MaxoPerf with k6 or Taurus. Configure an open workload model that steps up requests per second until you observe the ceiling:

• Start at a low sustained RPS that you know is safe — say, 10 RPS.
• Step up by 10–20 RPS every two minutes.
• Continue until you observe either 429/529 responses beginning, p99 latency exceeding your tolerance, or throughput plateauing despite the RPS increase.

The point where errors begin is your capacity ceiling. The difference between that ceiling and your expected peak is your headroom — or the gap you need to close.

Test 2 — Application resilience test under simulated inference degradation

This test targets your own application, not the inference provider. Run your application in a staging environment where the inference API (or a mock of it) can be configured to return slow responses or 429s. Then load-test your application with MaxoPerf at normal expected traffic:

• Hold normal traffic for 5 minutes.
• Switch the inference mock to return 429s with a Retry-After: 5 header.
• Hold for 5 minutes.
• Restore normal inference responses.
• Observe recovery.

Watch in results:

• Does your application’s error rate to end users increase when the inference provider returns 429s? If so, by how much?
• Does throughput recover cleanly after the inference provider recovers, or does a backlog cause your application to remain degraded?
• Are the user-facing error messages meaningful, or do they expose internal provider error codes?

These questions have concrete answers after a test. They do not have answers before one.

Run tests from MaxoPerf’s managed cloud locations to simulate realistic geographic load distribution, or use private/BYOC execution locations if your inference infrastructure is only reachable from inside your network.

Key takeaways

• No official root-cause analysis was published for this incident. The load cause discussed here is inferred and illustrative, not confirmed.
• AI inference capacity pressure is a real and growing risk. Demand for AI services grew faster than infrastructure provisioning cycles in 2025; teams building on inference APIs should plan for provider degradation as a normal operational scenario.
• Graceful load shedding matters more than total capacity. A system that returns 429s clearly and early is far easier for clients to handle than one that accepts every request until it becomes unavailable.
• Your application’s behavior during inference degradation is testable. You do not need to wait for a provider outage to learn how your system behaves — a mock inference backend configured to return 429s tells you everything.
• Breakpoint testing identifies the headroom gap. If you control your own inference infrastructure, the distance between your capacity ceiling (found by a breakpoint test) and your traffic forecast is the number you need to act on.