15 AI Vendors Publish an Uptime Number. I Checked Every One Against Its Own Incident Log. 11 Don't Add Up.

TL;DR: They log the outages. The uptime percentage printed above the outages does not reflect them. I audited 25 AI vendor status pages on August 15, 2026, over the fixed 90-day window May 17 to August 15. All 25 resolved, 15 publish a numeric uptime percentage, and 11 of those 15 publish a figure their own incident log cannot account for. Anthropic's page shows 99.36% for claude.ai, permitting 829 minutes of downtime across 90 days, while the same site's history lists 135 incidents totalling 42,580 minutes. This is not evidence of a hidden outage: both major status-page platforms document that "degraded performance" does not count against uptime at all. The four vendors whose numbers do reconcile are the four that measure uptime with an automated probe instead of deriving it from a human-toggled incident log.

A status page is the only uptime evidence most buyers see, and the company being measured publishes it. So I fixed a window, May 17 to August 15, 2026, which is 129,600 minutes, and went through 25 of them. Every page here was fetched between 22:14 and 22:40 PDT on August 15 (05:14 to 05:40 UTC on August 16). They update continuously, so anything you check later will differ. One mechanical note, because it produces a false zero: status.anthropic.com returns a 301 to status.claude.com, so a fetch that does not follow redirects sees an empty page.

Do the pages admit outages at all?

Mostly yes. All 25 resolved; 24 carried a readable incident history. Only Fireflies rendered nothing: status.fireflies.ai serves an empty client-side shell, and no JSON, RSS or history endpoint returned content.

The interesting split is the number on top. Fifteen of 25 publish a numeric uptime percentage: OpenAI, Anthropic, Cursor, GitHub, Replit, Perplexity, n8n, Otter, Vercel, Supabase, Together, Groq, OpenRouter, Cohere and Mistral. Nine publish none at all: Google Cloud, Lovable, Zapier, Clay, Granola, ElevenLabs, Fireworks, xAI and Deepgram. Publishing no number is not a dodge: Deepgram logged 14 incidents with clean timestamps and declines to average them, which beats averaging badly.

One structural detail, if you repeat this. OpenAI's status page front door shows four uptime bars, the line "We're not aware of any issues affecting our systems", and no incident list at all. The incidents sit one click away under History, where I counted 92. Its public API caps at 25 records, so an automated check sees a quarter of the log.

What does 99.68% actually permit?

Arithmetic first. Across 129,600 minutes, an uptime figure of X% permits (100 − X)% of that as downtime.

Vendor	Lowest uptime shown	Minutes allowed	Incidents	Minutes logged
OpenAI	99.68% (ChatGPT)	415	92	8,161 (25 of 92)
Anthropic	99.36% (claude.ai)	829	135	42,580
GitHub	99.43% (Actions)	739	73	8,493
Cursor	99.44% (Cloud Agents)	726	64	7,317
Supabase	99.85% (Edge Functions)	194	58	49,033
Vercel	99.90% (Dashboard)	130	35	5,413
Otter	99.71%	376	3	9,714
Cohere	99.95%	65	3	282
Groq	100% (all five components)	0	1	94

OpenAI's line is the conservative one: its 99.68% ChatGPT figure, labelled "May 2026 - Aug 2026", permits 415 minutes, and the 25 incidents its API returns (a subset of the 92 on the history page) already sum to 8,161. Anthropic's is the widest. status.claude.com publishes 99.36% for claude.ai against a log of 135 incidents and 42,580 minutes, which is 51 times the downtime that figure permits.

Groq is the cleanest case. groqstatus.com shows 100% for all five components, and its own log contains a July 1 incident titled "Data Center Failure Impacting Capacity" lasting 94 minutes. In plain English, 100% and 94 minutes cannot both describe the same 90 days. Under the platform's documented formula they can, which is the actual answer.

Why doesn't the number match the log?

Because neither platform computes uptime from the incident log. It comes from component status, and both exclude the most common category of failure.

Atlassian documents the Statuspage formula as "(Major outage minutes + (partial outage minutes * .3)) / total minutes in the period", calls it "an 'across the board' calculation" that "cannot be configured", and states that degraded performance and scheduled maintenance are "not considered for this feature" because degraded performance "isn't technically downtime". incident.io's rule is different in construction and identical in effect: only Full outage and Partial outage count as down, and Degraded performance is explicitly listed among the statuses considered up.

So Anthropic's log entry "Degraded performance of multiple models", open for 429 minutes on August 5, contributes zero to 99.36% if the component sat at degraded. Groq's 94-minute capacity failure contributes zero to 100% for the same reason. Every gap in that table is explained by this rule plus the 30% discount on partial outages, without anyone hiding anything. The number is not false. It answers a narrower question than the buyer's.

OpenAI prints the caveat under its bars: "Availability metrics are reported at an aggregate level across all tiers, models and error types. Individual customer availability may vary depending on their subscription tier as well as the specific model and API features in use." That is a vendor saying the number does not describe your experience.

Which vendors' numbers do reconcile?

Four, with one thing in common. They measure instead of declaring.

Together AI publishes per-model uptime from synthetic probes, with per-day labels like "Down for 7 hours and 13 minutes" and a worst figure of 93.043%. Nothing to reconcile, because the percentage is the measurement. Mistral publishes 95.973% for its Embeddings API and carried a live banner reading "ongoing for 3d 14h", which is 5,160 minutes against the 5,219 that figure permits. n8n reports daily ratios from an external HTTP monitor, averaging 99.985% with one bad day at 98.633%. OpenRouter shows 100%, and its window history holds one notice OpenRouter itself retracted as reported "in error" plus one completed maintenance.

The pattern is uncomfortable. The worst-looking uptime numbers in this audit belong to the vendors doing the most honest measurement. Mistral's 95.973% looks far worse than Groq's 100%, and it is the one you can trust. Same shape as AI coding productivity research, where the vendors ran most of the studies, and as AI note-takers, where not one of eight vendors publishes an accuracy figure.

Perplexity lands closest among the declarers: its 99.95% API figure permits 65 minutes against one logged API incident of 64. The Computer component still slips, 130 permitted against 524 logged. Replit is the eleventh: 99.87% over its 60-day chart permits 112 minutes, against one August 12 incident its own log marks "Resolved after 4h 23m".

What does this not prove?

It does not prove intent, and I am not claiming any. I cannot see a vendor's internal telemetry, I did not use these products during the window, and every gap above is fully explained by two published formulas. Running a status page well is hard, aggregate uptime across dozens of models is a real modelling problem, and many incidents are partial degradations that never crossed a documented threshold. A missing minute is far more often a definition than a decision.

What it does prove is that the number is not what you think it is. A status page percentage summarises how a component was labelled, not whether your requests succeeded, and here the two diverge by 51x. Nor can you add the pages up: four of the 20 vendors in a typical solo stack publish no machine-readable incident feed at all.

The document that binds a vendor is a different one. Probing each vendor's documented SLA path, I confirmed three: Google's Vertex AI SLA, Vercel's and Supabase's. An SLA defines downtime contractually, sets a threshold and pays you when it is missed, which is why it gets written far more carefully than a status page. If uptime matters, the question is not what the status page says. You already know. It is "what is your monthly uptime commitment, what counts as downtime, and what is the credit". Before signing the next annual contract, and the stack is expensive enough now that these are annual contracts, ask for the number with a penalty attached.