OpenAI Has the Most Incidents, Anthropic Resolves Fastest
OpenAI logged more status events than any other provider in a six-week study of 77 AI APIs. That's not a reliability problem—it's a surface area problem. OpenAI runs the most products, has the most API surface, and serves the most traffic. More moving parts means more opportunities for something to report degraded.
Anthropic logs fewer incidents, but the standout pattern is resolution time. When Anthropic posts an "investigating" status, it moves to "resolved" faster than the category average. Whether that reflects a smaller blast radius, tighter incident runbooks, or fewer services, the outcome is the same: shorter mean time to resolution.
The "Investigating" Phase Usually Ends Fast
When a status page flips from green to "investigating," developers go into triage mode. The data shows that in more than 80% of cases, the transition from "investigating" to "resolved" completes within two hours. Catastrophic multi-hour outages exist but are the exception.
Practical implication: a retry loop with exponential backoff covering the first 30–60 minutes handles the majority of incidents transparently to end users. Full circuit-breaker logic and cross-provider routing matter for the tail, not the median.
Status Pages Lag Reality by 10–20 Minutes
Official status pages are systematically late. The study recorded dozens of incidents where API probes showed elevated error rates, degraded latency, or 429 storms well before the corresponding status page acknowledged anything. The typical lag is 10–20 minutes. In some cases it's longer.
"Silent degradation"—where an API returns errors or slows down before any public acknowledgment—is the default incident pattern, not an edge case. If your alerting depends solely on status page webhooks, you have a 10–20 minute blind spot.
The Most Stable Services Might Surprise You
The services with the fewest incidents are Groq, Mistral, and Cerebras. All three are newer entrants, run narrower API surfaces, and focus almost exclusively on inference rather than operating multi-product ecosystems. Fewer integrations, fewer failure domains.
This isn't permanent—as these platforms grow, complexity tends to follow—but currently, if raw uptime is the top priority, smaller inference providers punch above their weight.
OpenAI and Anthropic Incidents Don't Correlate
OpenAI incident windows do not meaningfully overlap with Anthropic incident windows. Their infrastructure, scaling events, and failure modes are largely independent.
This is the empirical case for routing across providers. If you have a fallback path from an OpenAI call to an equivalent Anthropic call, the two failure probabilities multiply rather than add. The redundancy is real.
What This Means for How You Build
-
Design for the degraded state. Most AI API failures are partial—elevated latency, elevated error rates, not a total blackout. Streaming with timeouts, graceful fallbacks to cached responses, and user-facing "AI is slow right now" messaging all perform better than assuming the API is binary up or down.
-
Don't use the status page as your real-time signal. Use it for incident communication and post-mortems. For real-time detection, run your own probes.
-
Route across independent failure domains. The OpenAI/Anthropic correlation data supports this directly. Treating providers as interchangeable based purely on model capability misses the reliability dimension.
Add Status Checks to Your Own Monitoring
Prismix exposes a public REST endpoint with no API key required:
GET https://prismix.dev/api/v1/statuses
It returns current status for all 77 services in a single JSON response. Drop it into your existing health check pipeline, your Grafana dashboard, or your on-call runbook.
The dashboard itself is at prismix.dev—free, no account required. If you're building on top of AI APIs and not watching the upstream services you depend on, this is the lowest-effort way to start.
We'll keep publishing findings as the dataset grows. Six weeks is a start; six months will be more interesting.
