Every developer who has shipped an AI-powered feature knows the moment. Your logs light up with 500s or timeouts, your users are reporting failures, and your first instinct is to open a new tab and type "is OpenAI down." The status page loads green. You stare at it for a second. Then you go check Twitter.
That gap between "something is clearly wrong" and "the status page admits something is wrong" is where real incidents live — and it's what motivated us to build Prismix.
How we collect the data
For the past six weeks, Prismix has been polling the official status pages and running direct API health probes against 77 AI services every five minutes. That includes the obvious ones — OpenAI, Anthropic, Gemini, Mistral, Groq, Perplexity, GitHub Copilot, DeepSeek — plus the growing wave of image, audio, and video generation services: ElevenLabs, Runway, Replicate, Stability AI, and dozens more.
Each probe records response latency, HTTP status codes, and whether the official status page matches what we're actually seeing. The result is a dataset of thousands of polling cycles per service, spanning incidents both small and significant.
Here's what we found.
OpenAI leads in incident volume — Anthropic leads in resolution speed
By raw incident count, OpenAI has more status events than any other provider in our dataset. That's not a knock on their reliability — it's a function of surface area. 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.
What's interesting is the contrast with Anthropic. Anthropic logs fewer incidents by count, but the pattern that stands out is resolution time. When Anthropic posts an "investigating" status, it tends to move to "resolved" faster than the category average. Whether that reflects a smaller blast radius, tighter incident runbooks, or simply fewer services in play, the outcome is the same: shorter mean time to resolution.
The "investigating" phase is where developers panic — but it usually ends fast
When a status page flips from green to "investigating," developers go into triage mode. Do we fall back to a different model? Do we queue requests and wait? Do we page someone?
The data suggests: in more than 80% of cases, "investigating" → "resolved" completes within two hours. Most incidents are shorter than that. Catastrophic multi-hour outages exist — we've recorded several — but they're the exception, not the pattern.
The 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 matters for the tail, not the median.
Status pages lag reality by 10–20 minutes — consistently
This is the finding that surprised us least but that developers most need to hear explicitly: official status pages are systematically late.
We've recorded dozens of incidents where our 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 significantly 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 by design.
The most stable services might surprise you
The services with the fewest incidents in our dataset 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 a permanent characteristic — as these platforms grow, complexity tends to follow — but right now, if raw uptime is the top priority for a workload, the smaller inference providers punch above their weight.
OpenAI and Anthropic incidents don't correlate
One of the more useful findings for system design: OpenAI incident windows do not meaningfully overlap with Anthropic incident windows. Their infrastructure, their scaling events, and their 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, not theoretical.
What this means for how you build
A few practical conclusions from six weeks of data:
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, you need 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 — 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 you're 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.
Top comments (0)