ChatGPT, Claude, and Gemini: A Reliability Comparison Based on Real 2026 Incident Data

When ChatGPT, Claude, or Gemini goes down, it's not an abstract infrastructure event - it's a broken product feature, a failed customer demo, a stalled AI pipeline, or an engineer blocked mid-task. Developers building on these APIs treat uptime the way they'd treat any production dependency.

We pulled incident data directly from the public status pages of all three providers: status.openai.com, status.claude.com, and status.cloud.google.com (Vertex AI/Gemini API). All data below comes from those sources, not third-party trackers.

How Each Provider Publishes Incidents

Before the numbers: the three providers handle incident disclosure very differently. That difference affects what you can and can't measure.

OpenAI publishes the most incidents by volume - including narrow, short-lived events affecting specific user tiers or features. Google publishes the fewest, but each published incident comes with a detailed postmortem. These aren't apples-to-apples comparisons of reliability; they're comparisons of disclosure philosophy, which itself tells you something.

OpenAI / ChatGPT: 90 Incidents in ~90 Days

OpenAI's public feed contained 90 incidents from roughly January through June 26, 2026 - averaging one per day across the period covered.

Volume by month (approximate)

The trend is upward through the period. April–June 2026 saw noticeably more incidents than early in the year, which aligns with the rapid product expansion OpenAI ran in this period - Codex, new model releases (GPT-5.5, GPT-5.5 Thinking, gpt-5.5-mini), and Sora all launched or expanded significantly.

Breakdown by affected service

Codex was the single most incident-prone service - nearly one incident every 4 days. This makes sense: Codex launched in this period and scaling a new coding agent product that integrates multiple models, file systems, and external APIs creates complex failure surfaces that mature over time.

The most significant OpenAI incidents

April 20 - Full ChatGPT platform down

The most impactful incident in this period: login, conversations, voice mode, search, image generation, Codex, APIs, and the Connectors system all went down simultaneously. OpenAI's status page posted "Users unable to load ChatGPT, Codex and API Platform" as a single incident affecting essentially every product component.

June 3 - Elevated error rates across ChatGPT Pro, Codex, and Responses API

Two incidents fired on the same day affecting ChatGPT Pro users (conversations, image generation, deep research) and Codex + Responses API. Both resolved the same day. The simultaneous nature of these two incidents suggests a shared infrastructure dependency.

June 12 - Elevated 431 errors

HTTP 431 (Request Header Fields Too Large) errors across Files, Embeddings, Moderations, Responses, Login, Batch, and Fine-tuning. A 431 surfacing across unrelated endpoints simultaneously indicates a shared proxy or API gateway configuration issue, not an application-layer bug.

June 18 - ChatGPT failing to load or save

Conversations, image generation, voice mode, search, connectors, and Atlas all affected. Resolved the same day. OpenAI published no root cause beyond "all impacted services have fully recovered."

What OpenAI doesn't tell you

OpenAI's incident reports consistently close with "All impacted services have now fully recovered" and no root cause. Across 90 incidents, detailed postmortems are rare. You get high incident frequency and transparent disclosure that something happened, but minimal insight into why.

The June 6 incident was an exception: "Incorrectly suspended users have been restored access and received an email about their account and subscription information." That's an account management failure, not an infrastructure failure - but it suggests some incidents are caused by data pipeline or policy automation errors, not just server load.

Anthropic / Claude: 25 Incidents in 14 Days

The Claude status feed contained 25 incidents from June 10–24, 2026 - roughly 1.8 per day. The feed's depth is shorter than OpenAI's, so we can't compare January–June totals. But the density within the June window is notable.

June 2026: Claude Opus 4.8 instability

The dominant story in Claude's June 2026 incident log is a single model: Claude Opus 4.8. Seventeen of the 25 incidents in the feed directly name Opus 4.8 as the affected service.

June 17 had four separate Opus 4.8 incidents, spread across morning, midday, and afternoon UTC. These weren't a single multi-hour event - they were distinct degradations that resolved and recurred throughout the day.

The June 16 multi-model incident

The most significant Claude incident in this window: June 16, elevated errors across many models, with two distinct phases.

Phase 1 (17:23–18:00 UTC): All Sonnet and Opus models affected, reaching a ~10% error rate.

Phase 2 (18:00+ UTC): Sonnet and Opus 4.6 recovered; Opus 4.8 continued with elevated errors for another period.

Anthropic's postmortem was more detailed than OpenAI's typical response: the two-phase nature of the incident, the exact UTC window, and the per-model recovery status were all documented.

June 22 - Widest model impact

On June 22, a single incident affected Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 4.6, and Haiku 4.5 simultaneously. Anthropic posted recovery updates per model as each came back:

"Opus 4.7 has recovered" ... "Haiku 4.5 has recovered"

This pattern - cascading per-model recovery - suggests a shared dependency across model families rather than a model-specific issue. An inference cluster, routing layer, or rate limiting system that all models share is the more likely failure point than a problem with any individual model's weights.

June 23 - Three incidents in one day; model access suspended

Three incidents fired on June 23, all resolved. Also on June 23, Anthropic posted a notice that access to Claude Mythos 5 and Claude Fable 5 had been suspended, pointing to an Anthropic blog post for context. This isn't a typical infrastructure incident - it suggests new model deployments were pulled back after issues, a different class of reliability event.

What Anthropic's data reveals

The Opus 4.8 pattern suggests a new model that shipped with scaling or stability issues that weren't fully resolved at launch. The June 16–24 window had Opus 4.8 incidents nearly every day, often multiple times. For developers building on the Claude API, this period represented a week-plus of unreliable access to Anthropic's flagship model.

Anthropic's disclosure quality is better than OpenAI's in terms of specificity - exact UTC windows, per-model recovery status, explicit error rates - but the incident volume in June was unusually high.

Google / Gemini: Fewer Published Incidents, More Detailed Postmortems

Google's Vertex AI Gemini API status page contained one Gemini-specific incident from 2026 in the public JSON feed, plus a major ongoing Google Cloud infrastructure event.

February 27, 2026 - All Gemini models down for 1 hour 58 minutes

This is the most thoroughly documented incident in this entire analysis. On February 27, 2026 at 04:37 US/Pacific, all Vertex AI Gemini API models experienced increased error rates. This included every version of Gemini in production: gemini-2.5-flash, gemini-2.5-flash-lite, gemini-2.5-pro, gemini-3.0-flash-preview, gemini-3.0-pro-preview, gemini-2.0-flash, and gemini-2.0-flash-lite.

Root cause (verbatim from Google's postmortem): "A configuration change to a safety filtering service that supports all Gemini models. For some specific requests, this created code paths that eventually led to service disruptions and capacity loss for the safety filtering service."

Error experience:

• PayGo customers: 429 Resource Exhausted errors
• Provisioned Throughput customers: 503 Service Unavailable errors

Duration: 1 hour 58 minutes total. PT customers recovered by 06:00 Pacific. PayGo customers recovered by 06:20 Pacific.

Cascading impact: Dialogflow CX, Agent Assist, and Google Cloud Support AI (all of which depend on Gemini) were also affected.

Geographic scope: Global endpoint, us-central1, us-east4, and other US regions.

Google's postmortem included explicit preventive actions:

• Reinforcing rollout processes with mandatory validation checkpoints
• Improving alerting on critical dependencies

This is the kind of detailed, accountable postmortem that the industry benchmarks against. The root cause is specific, the timeline is exact, the affected customer segments are distinguished, and the preventive measures are named.

June 5–26 (ongoing) - Delhi data center fire causes network degradation

A fire at a third-party data center facility in Delhi required an emergency power shutdown of networking equipment, isolating Google Cloud's local Point of Presence. This disrupted network routing for Google Cloud customers in India and surrounding regions.

Affected products: Hybrid Connectivity, Virtual Private Cloud (VPC), Media CDN.

Duration: As of June 26, 2026 - still ongoing, 21+ days since the fire. Traffic is being rerouted through alternative capacity while the facility is restored.

This incident doesn't directly affect the Gemini API for most users, but it affects Google Cloud broadly and illustrates infrastructure risk.

The disclosure gap

Google publishes far fewer incidents than OpenAI or Anthropic. This doesn't mean Google has fewer outages - it means fewer events meet Google's threshold for a public status post. The February 27 incident was a nearly two-hour global outage affecting every Gemini model. That's clearly above any threshold.

What's missing from the public record: shorter degradations, model-specific elevated error rates, partial availability events. Google AI Studio and the consumer Gemini app have no publicly accessible, machine-readable incident feed. Developers building on these services have less incident history to reference than OpenAI or Anthropic users do.

Comparison: What the Data Shows

What This Means if You Build on These APIs

For OpenAI: The incident frequency is high, but most events resolve quickly. The risk profile matches what you'd expect from a company shipping new products at pace. Codex is the most volatile surface. The Responses API and Conversations have been reliable compared to newer products. The lack of postmortem detail means you're managing alert fatigue more than learning from incidents.

For Anthropic: June 2026 was a rough month specifically for Claude Opus 4.8. If you build on Opus 4.8 as your primary model, that period meant daily or near-daily disruptions. The multi-model incidents (June 16, June 22) show that Anthropic's infrastructure has shared failure points across model families. On the positive side: Anthropic's status updates include specific error rates, UTC windows, and per-model recovery - useful for postmortem documentation on your side.

For Google (Gemini): The low incident count reflects limited public disclosure more than proven reliability. The February 27 outage was a genuine wide-scale failure, but the postmortem quality was significantly better than either of the other two providers. For developers using Vertex AI Gemini, the transparency is better than the consumer-facing APIs, but the incident feed is shallow.

The Pattern Across All Three

All three providers are introducing new models faster than their stability track records can verify. Claude Opus 4.8 appeared to ship with unresolved scaling issues. OpenAI's Codex launched into a period of near-daily incidents. Google's safety filter configuration change in February took down every Gemini model globally.

The shared root cause in each case: configuration changes and new deployments that interact poorly with dependencies or hit capacity limits at scale. None of the three major incidents (OpenAI April 20, Claude June 16, Google February 27) were hardware failures or network events. They were software and configuration changes that went wrong.

For teams integrating LLM APIs into production workflows, the practical implication is the same regardless of which provider you use: build for intermittent unavailability, implement retry logic with exponential backoff, and consider fallback models for critical paths. The AI API layer is not yet as stable as the compute and network infrastructure layers that run beneath it.

Data sourced directly from status.openai.com, status.claude.com, and status.cloud.google.com/incidents.json. Atom feeds are limited to the most recent entries; OpenAI's feed contained entries back to approximately January 2026, Claude's feed covered June 10–24, 2026, and Google Cloud's JSON contained 3 incidents. Incident counts reflect published events only and do not represent a complete outage history for any provider.