Published: 2026-07-28
Categories: AI Concentration Risk
Key Takeaways
On the morning of July 25, 2026, OpenAI’s ChatGPT, its developer API, and its Codex coding platform failed simultaneously in a worldwide outage that The Next Web reported as the fourth service disruption within four days [3]. The failure was not an isolated glitch: OpenAI’s status history in the days leading up to July 25 shows a recurring pattern of elevated error rates and outages, including a Wednesday and Thursday disruption and a separately flagged major outage on July 23, culminating in the July 25 incident that took down all three product lines at once, with requests failing behind an internal circuit-breaker error labeled “biscuit_baker_service_me_circuit_open” [3]. Enterprises that have built customer-facing features, coding pipelines, and agent workflows on a single model provider typically have no fallback path in an outage window of this kind — a structural exposure this incident illustrates rather than a claim verified for every affected organization. This pattern is consistent with the concentration risk that CSA’s AI Safety Initiative has been documenting since May 2026: a small number of frontier model providers now sit underneath a disproportionate share of enterprise AI activity, and a shared-backend failure at any one of them propagates instantly across every dependent organization [4][5]. The July 25 incident is consistent with, and adds a further data point to, the concentration-risk pattern CSA’s research has modeled as structural rather than incidental.
Background
OpenAI’s outage began at approximately 5:11 a.m. ET on July 25, 2026, when the company’s status page acknowledged elevated error rates across ChatGPT, the developer API, and Codex without offering a root cause or a recovery estimate [2]. Within an hour, Downdetector reports had spiked from a baseline of roughly three to more than 2,000, with affected users spanning the United States, Europe, India, Japan, and Australia [3][6]. ChatGPT’s outage manifested as a frozen loading animation and “too many concurrent requests” errors that blocked new messages and made prior conversations inaccessible; the API returned errors across a reported twelve endpoints, and Codex failed across four of its own components [1][3]. OpenAI applied a fix and moved from “investigating” to “monitoring” within roughly an hour, and ChatGPT was substantially restored by approximately 6:00 a.m. ET, though the company’s public statements were limited to the standard line that it was “investigating the issue for the listed services”; OpenAI did not disclose a root cause, address the preceding week’s pattern of incidents, or comment on downstream customer impact [1][2].
What makes this incident notable is not its duration, which was comparatively brief, but its place in a documented sequence. The Next Web characterized the July 25 failure as the fourth service disruption within four days, describing a run of incidents earlier that week — including a Wednesday and Thursday disruption and a separately noted major outage on July 23 — before the July 25 event took ChatGPT, the API, and Codex down together [3]. Independent monitoring of OpenAI’s status page has tracked 354 outages since January 2025, an average of roughly 18 per month [7]. Two of those incidents, on April 20 and July 23, 2026, were significant enough to draw separate press coverage, and a distinct multi-day outage affecting image generation ran from July 21 to July 22, 2026 [7]. One outlet argued that an outage is an inconvenience, but a weekly outage is a reliability problem, noting that the recurrence is happening at the same time OpenAI is pushing ChatGPT into more consequential use cases, including work-oriented products, medical questions, and record-keeping [6]. The scale of exposure is what turns a vendor’s reliability problem into a systemic one: OpenAI has reported more than 900 million weekly active users and more than 10 million users of its agentic features, meaning that a single shared-backend failure has the potential to interrupt a population of users and dependent applications larger than the population of most countries [3][8].
Security Analysis
The security-relevant fact about the July 25 outage is not that OpenAI’s infrastructure failed, but that ChatGPT, the API, and Codex failed together, behind what reporting describes as a shared backend layer rather than three independently engineered services [2]. When a foundation-model provider’s control plane, authentication layer, or request-routing tier goes down, every product built on top of it goes down in the same instant, regardless of how well the downstream application itself was engineered. This is the operational signature of concentration risk: resilience investments made at the application layer, such as retry logic, caching, or graceful degradation, cannot compensate for an outage at the model layer itself, because there is no independent path to the underlying capability. CSA’s research on AI compute and provider concentration has argued exactly this point since May 2026, observing that a small number of hyperscalers and frontier model providers now sit beneath enterprise AI deployment broadly enough that “the failure, disruption, or adversarial compromise of any link in that chain propagates broadly” across every dependent enterprise, and citing documented OpenAI and Anthropic outages as the illustrative case even before the July 25 incident occurred [4].
The downstream consequences of the outage extended well past the roughly one-hour window in which OpenAI’s own services were degraded. Startups and enterprises that have built customer-facing features on the OpenAI API reported broken functionality and missed service-level targets during the outage [2]. Reporting on the incident also raised interrupted multi-step agent workflows as a forward-looking concern for organizations running autonomous agents on top of ChatGPT, rather than as a documented effect of this specific outage — though the underlying exposure, an agent halting mid-task with no fallback execution path, is the same risk CSA’s research has flagged regardless of whether it materialized on July 25 [3]. This asymmetry, in which a brief upstream failure produces an extended or unpredictable downstream disruption, is the mechanism CSA’s research has flagged as the core problem with treating foundation-model dependency as an ordinary vendor relationship. An enterprise that depends on a cloud email provider can tolerate an outage and, if necessary, migrate providers over a period of weeks; an enterprise that has built its detection playbooks, customer support flows, or coding pipeline around a specific model’s behavior does not have an equivalent switching option in the moment of failure, and often does not have one at all in the short term [4]. CSA’s insurance-focused research on foundation model concentration adds a second layer to this same argument, noting that when a widely used model experiences a regression, an outage, or a safeguard failure, the resulting losses are correlated across every enterprise that depends on that model simultaneously, rather than being the independent, diversifiable losses that insurance pricing and enterprise risk registers are built to absorb. That research cites the concrete data point that both OpenAI and Anthropic have each individually exceeded three days of cumulative annual downtime, with cascading effects on the services built on top of them, a figure that situates the July 25 incident as one data point within an already-elevated baseline rather than an anomaly [5].
The recurrence pattern itself is a second, distinct signal worth separating from any single incident. The Next Web’s characterization of July 25 as the fourth service disruption within four days sits inside a broader spring and early-summer pattern that already included a major April 20 outage, a July 21–22 image-generation outage, and a July 23 outage, and it points to a provider operating with a materially non-trivial baseline failure rate rather than an occasional, unpredictable disruption [3][6][7]. For enterprise risk purposes, a roughly 18-incidents-per-month cadence changes the character of the exposure: it is no longer a tail risk to be modeled as a rare event, but a recurring operational condition that should be planned for in the same way an enterprise plans for scheduled maintenance windows or known regional cloud outages, except without OpenAI publishing a maintenance schedule or a committed service-level agreement that most enterprise customers can act on [6].
Recommendations
Immediate Actions
Security and platform teams should confirm, for every internal system and customer-facing product that calls the OpenAI API, whether a July 25-style multi-hour or multi-incident outage produced a silent failure, a queued backlog, or a user-visible error, and should capture that impact data now while logs and support tickets are still fresh. Teams operating autonomous or multi-step agents on top of ChatGPT or the API should verify that in-flight agent tasks failed safely during the outage window rather than partially completing, since an agent that stops mid-task without a clear resumption or rollback mechanism can leave systems, files, or customer records in an inconsistent state.
Short-Term Mitigations
Enterprises should treat foundation-model dependency as a named line item in their third-party risk registers, distinct from generic “AI risk,” and should require that line item to include the vendor’s actual incident history rather than its marketed uptime figures, since a status page showing dozens of monthly incidents tells a different story than a headline availability percentage. Application architectures that currently hard-code a single model provider should be reviewed for the feasibility of a fallback path, whether that means a secondary model provider, a degraded-but-functional local mode, or an explicit user-facing failure state that avoids silent data loss, and contracts with model providers should be renegotiated where possible to include advance notice of planned changes, defined incident-communication timelines, and data-portability guarantees.
Strategic Considerations
Over the medium term, enterprises with material AI-dependent revenue or safety-critical workflows should build and maintain a foundation-model dependency inventory that identifies, for each business-critical process, which specific model or provider it depends on and what the actual business impact of an hour-long, day-long, or week-long outage at that provider would be. This inventory should feed directly into architectural decisions about multi-model diversification and into governance conversations about which workflows are appropriate candidates for a single-provider dependency at all, particularly as providers continue to position their products for higher-stakes use cases such as workplace tools, health-related applications, and autonomous agent execution, where an outage carries consequences well beyond a delayed chat response.
CSA Resource Alignment
This incident is additional evidence supporting the structural argument in CSA’s Foundation Model Concentration: The Uninsurable AI Risk (July 6, 2026), which had already identified OpenAI and Anthropic’s combined annual downtime as evidence that foundation-model dependency produces correlated losses across dependent enterprises rather than the independent, diversifiable losses that insurance and enterprise risk frameworks are built to price [5]. The July 25 outage, occurring roughly three weeks after that research was published, is consistent with the kind of upstream failure the paper describes: a single shared-backend disruption that simultaneously affects every enterprise relying on that provider, regardless of how each enterprise’s own application layer was engineered.
CSA’s AI Compute Concentration and Systemic Risk (May 9, 2026) makes the complementary point at the infrastructure layer, arguing that the concentration of AI compute and model provision among a small number of firms means “the failure, disruption, or adversarial compromise of any link in that chain propagates broadly,” and it cites prior documented OpenAI and Anthropic outages as its illustrative evidence for exactly this dynamic [4]. The July 25 incident, and the pattern of disruptions surrounding it, extends that evidence base rather than introducing a new category of risk.
Both papers connect to CSA’s AI Controls Matrix (AICM v1.1), which enterprises should use to formalize foundation-model dependency as a documented, assessed risk rather than an informal assumption. AICM’s supply chain and risk management control domains provide the structure for the dependency inventories, vendor continuity provisions, and multi-provider architecture reviews recommended above, giving security and risk teams a standing framework to apply the lessons of this specific outage to future provider selection and contract negotiation decisions.
References
[1] Bill Toulas. “OpenAI confirms ChatGPT is down worldwide.” BleepingComputer, July 25, 2026.
[2] Unite.AI Staff. “Global Outage Hits OpenAI’s ChatGPT, API and Codex.” Unite.AI, July 25, 2026.
[3] TNW Staff. “OpenAI hit by another outage as ChatGPT, Codex, and APIs go down together.” The Next Web, July 25, 2026.
[4] Cloud Security Alliance AI Safety Initiative. “AI Compute Concentration and Systemic Risk.” CSA Labs, May 9, 2026.
[5] Cloud Security Alliance AI Safety Initiative. “Foundation Model Concentration: The Uninsurable AI Risk.” CSA Labs, July 6, 2026.
[6] IBTimes Singapore Staff. “Breaking: ChatGPT Is Down Again And OpenAI’s Status Page Shows a Pattern.” IBTimes Singapore, July 25, 2026.
[7] StatusGator. “OpenAI Outage History.” StatusGator, accessed July 28, 2026.
[8] Julia Love. “ChatGPT Has Almost 1 Billion Weekly Users, OpenAI Says.” Bloomberg via Yahoo Finance, 2026.