Between July and September 2026, Claude's status page posted 93 incidents and OpenAI's posted 96. A count on a provider's own page measures how often something broke and how the provider decides what to post. Durations within one provider are the steadier series, and your own request logs are the survey.
Between July 1 and September 30, 2026, the status page for Anthropic's Claude posted 93 incidents. The status page for OpenAI posted 96. If you were picking a model API on reliability, that is about as close to a tie as public data gets.
Then look at the months. Claude's page went 55, 25, 13. OpenAI's went 36, 20, 40.
Did Claude become four times more reliable over one summer while OpenAI slumped and recovered? Nothing on either page can tell you. A count of incidents on a provider's own status page measures two things at once: how often something broke, and how the provider decides what to post. Pull the pages apart and you can see which numbers carry which, and which ones a developer can actually use.
Both pages publish machine-readable data, and they run on different software.
status.claude.com (status.anthropic.com now answers with a permanent redirect to it) runs Atlassian Statuspage. Its history endpoint pages back to the first incident the page ever posted, in March 2023: 922 incidents through October 1, 2026. Each one carries a grade (none, minor, major or critical) and a UTC stamp from first post to resolution.
status.openai.com runs incident.io. Its public history page embeds one quarter of data, 97 incidents from July 1 to October 1, 2026. For each incident it records something different: which components were affected, for how long, and how badly, on a scale of degraded performance, partial outage and full outage.
Both also serve the standard /api/v2/incidents.json feed, and that feed is the first trap. It returns the latest N incidents: 50 on Claude's page, 25 on OpenAI's. Read on October 2, Claude's 50 ran from July 25 to October 1 and OpenAI's 25 from September 13 to September 30. A week earlier the same two URLs covered different weeks. Compare those two numbers as rates and you are comparing two window sizes.
The only fair comparison is a fixed window that both histories cover. That window is July through September 2026, and it produces the near-tie above.
This is not the first count. Xiaoyu Chu, Sacheendra Talluri, Qingxian Lu and Alexandru Iosup mined the same pages for a paper at ICPE 2025. Their data ran from February 2021 for OpenAI and from July 2023 for Anthropic, both through August 2024. Their headline finding: "Failures in OpenAI's ChatGPT take longer to resolve but occur less frequently than those in Anthropic's Claude." The median time to recovery was 1.23 hours for OpenAI's API and 0.77 hours for Anthropic's.
The duration half of that finding still holds two years later. Over the shared 2026 quarter, the median Claude incident ran 1.07 hours from first post to resolution, and the median OpenAI incident ran 1.80 hours.
One caution sits under those two medians: they come from slightly different clocks. Claude's runs from the first post to the resolved stamp. OpenAI's runs from the moment the first component went degraded to the moment the last one recovered. For the 18 recent OpenAI incidents where both clocks exist, the two agree to the minute in the median case and differ by more than nine hours in the worst one.
The frequency half is where counting gets hard, and the authors said so in their own limitations section: "The accuracy of our failure dataset is limited to what the LLM operators themselves report. That makes our data subject to the operators' bias."
If the count mixes reliability with policy, maybe the grades can untangle it. A count weighted by severity would beat a raw count, as long as the severity means something you can check. The simplest check is time. On the whole, a major incident ought to last longer than a minor one.
It doesn't, on either page.
On Claude's page, across 800 graded incidents since 2023, the median minor incident lasted 1.07 hours, the median major one 1.13 hours, and the median critical one 0.85 hours. The rank correlation between grade and duration is −0.04, which is to say there isn't one.
On OpenAI's page, as read on October 2, the relation runs backwards. The 67 incidents whose worst status was degraded performance had a median duration of 2.00 hours. The 11 partial outages had 0.89 hours, and the two full outages a median of 29 minutes. The rank correlation is −0.22.
There is a likely story for the reversal: a full outage gets everyone on the call and gets fixed fast, while a partial degradation can drift through an afternoon without anyone treating it as an emergency. But that is a story, not a finding. The data supports something narrower. The grade does not measure duration. It tracks breadth slightly better: across Claude's latest 50 incidents, grade and the number of products an incident names correlate at 0.28, and over OpenAI's quarter at 0.19. Both are weak. The grade is the provider's judgment of how bad an incident looks, made in the moment by whoever writes the post.
That judgment also moved over time. On a single page, with one provider and one piece of software, you can watch the counting rules change.
| Claude's status page | 2023 | 2024 | 2025 | 2026 (to Oct 1) |
|---|---|---|---|---|
| incidents posted | 30 | 191 | 335 | 366 |
| graded "none" | 50% | 19% | 13% | 6% |
| graded "minor" | 33% | 35% | 51% | 62% |
| graded "major" or "critical" | 17% | 44% | 36% | 32% |
| opened and closed within 5 minutes | 53% | 12% | 7% | 6% |
| median hours, first post to resolution | 0.03 | 1.02 | 1.13 | 0.98 |
| resolved within 2 hours | 83% | 69% | 72% | 73% |
In 2023, half of Claude's incidents were posted with no impact grade, and half were opened and closed within five minutes. Those were notices written after the problem was already over. By 2026 both kinds had nearly disappeared. The page now posts while things are happening, and it grades almost everything, mostly as minor.
Read the grade rows alone and you might report that major and critical incidents fell from 44 percent of the total in 2024 to 32 percent in 2026. That describes labeling as much as outages. Over the same years the "none" share fell from 50 percent to 6, and those incidents didn't stop happening. They moved into a grade.
Now look at the last two rows. From 2024 on, the median time from first post to resolution stayed between 0.98 and 1.13 hours, and the share fixed within two hours stayed between 69 and 73 percent. (The tiny 2023 median is the after-the-fact notices: an incident posted when it is already over lasts two minutes on paper.) While the yearly count kept climbing and the grades reshuffled, durations held still. Within one provider, duration is the steadiest series on the page.
England and Wales have run this experiment at national scale, with crime.
Crime there is counted two ways. The police record the crimes reported to them. A household survey, the Crime Survey for England and Wales, asks people what happened to them whether or not they told the police. In 2014 the UK's statistics regulator took away the police figures' National Statistics status. As its 2024 review puts it, an assessment "found evidence that the quality and consistency of the underlying data may not be reliable." Inspections had found that 19 percent of the crimes reported to the police were never recorded as crimes. The two series had drifted apart, and the drift pointed at the recording, not at the crime.
Then forces cleaned up their recording. By the 2021–22 inspections, recording accuracy had risen from 80.5 percent in 2014 to 92.4 percent. And the police count went up.
The regulator's 2024 review sets the two series side by side. The survey shows "a long-term fall in the extent of crime estimated by the survey since the mid-1990s." Police-recorded crime, meanwhile, "has increased gradually since 2015, largely due to improvements to police recording processes and practices." The ratio of police-recorded crimes to survey crimes went from 0.68 in the year to March 2013 to 1.93 ten years later. Better recording made the count look worse.
That is the shape of Claude's table. A provider that starts posting live, grades everything and tags incidents by product will see its count climb for reasons that have nothing to do with its servers. A provider that raises its posting threshold will look better overnight. To be fair to the statisticians, they don't claim recording explains the whole gap: the Office for National Statistics also points at falling survey response rates. The lesson survives anyway. You cannot read an institution's own count without knowing its recording rules.
The statisticians have a working answer. The Office for National Statistics publishes which source it prefers for which crime:
The serious, visible events, too big to go unrecorded, are the ones where the institution's own count wins.
Status pages have their homicides too, and Chu and colleagues make the matching point. Citing earlier studies, they write that operators' reports "already capture the most user-visible failures as those generate widespread social media coverage, making it difficult for the operators to hide failure." A full outage of a chatbot used by millions does not go unposted. A ten-minute rise in API errors for one model in one region is a judgment call, and judgment calls are where policy lives.
Pull the longest entries out of Claude's history and the definition of an incident widens again.
The longest "critical" incident ran 450 hours, from June 13 to July 1, 2026. Its title reads "We’ve suspended access to Claude Mythos 5 and Claude Fable 5". That is an access decision, posted on a status page. The second longest, 212 hours in September 2025, was titled "Model output quality": a regression in answers, not a failure to answer. Both are things a status page should tell you. Both sit in the same count as a twenty-minute burst of server errors.
Products inflate the count a different way. Claude's latest 50 incidents name claude.ai 38 times, Claude Code 35 times, Claude Cowork 35, the Claude API 34 and the Console 9. Shares by product add up to far more than 100 percent, because one incident can name all five products, and 31 of the 50 name four or more. A count by product measures how the page tags incidents at least as much as where things fail. Chu's paper found that any two Anthropic services were more than 80 percent likely to report outages on the same day, and read that as "a severe lack of isolation across different services." From outside the company, a lack of isolation and a habit of tagging one incident with several products look the same.
Even the clock is set by people. In all of Claude's latest 50 incidents, the start time the page gives is within a minute of the moment the incident was posted. The page measures from when someone posted, not from when the fault began. Both pages also post most of their incidents between noon and midnight UTC: 67 percent on each over the shared quarter. Those are working hours in American time zones, when people are around to notice a problem and write it up. The hour of posting tells you about the people as much as about the system.
None of this makes status pages useless. It makes them one particular instrument, good for some measurements and misleading for others.
Don't compare incident counts across providers. 93 against 96 describes two posting policies, two pieces of software and two ways of splitting products. It is not a reliability ranking.
Don't trend one provider's count across years either, unless you can show its posting rules held still. Claude's own page shows they didn't.
Use durations within one provider as a series. The median time to resolution and the share fixed within two hours are the steadiest numbers on Claude's page. If that median doubles, either something real changed or the clock definition did, and both are worth asking about.
Trust the severe end more than the mild end. Full outages are the homicides: hard to hide, so the page records them. At the minor end, posting policy decides what gets recorded at all.
Run your own survey. For an API, the crime survey's job is done by your own telemetry. Log every request your system makes to a model provider, with its status code and its latency, and count your own error minutes per provider per week. That number keeps one definition across providers and over time, because you wrote it. When your log shows an error burst the status page never posted, you have found the gap the page doesn't record. When the page posts an incident your traffic never saw, you have learned something about its threshold.
If you run a status page yourself, publish what your grades mean and note when you change your posting rules. A footnote that says "from March we post every elevated-error event longer than five minutes" turns a jump in your count from an alarm into a fact.
The near-tie at the top of this piece is real; it just measures less than it seems to. Read a status page the way Britain's crime statisticians read police records. Believe it for what was too big to hide, and measure the rest yourself.
history.json, pages 1–16) and https://status.claude.com/api/v2/incidents.json, read October 2, 2026. https://status.anthropic.com returns HTTP 301 to it.Chain of Consciousness keeps a tamper-evident, dated record in hash-linked entries. Log each change to what your grades mean or when you post, and the weekly error minutes your own telemetry counts, and a jump in a count can be checked against the date its definition moved.
pip install chain-of-consciousness npm install chain-of-consciousness
Or start without installing anything: Hosted Chain of Consciousness.