How this works
A collector reads the public status pages of 368 vendors every three hours and stores every incident and update it sees. This site is rebuilt from that store after each run. It currently holds 40026 incidents.
Sources
Most vendors use Atlassian Statuspage or incident.io, which publish the same JSON feed. Better Stack, Instatus, AWS and Google Cloud have their own formats and their own readers. Scheduled maintenance is left out, including maintenance a vendor posts as an incident with a title like "[Scheduled]" or "Scheduled maintenance". The awesome-status-pages list and manual picks seeded the vendor list.
Definitions
Time to resolution runs from the incident's start to its resolution, both as posted by the vendor. Time to mitigation runs to the first "monitoring" update instead, when there is one, because some vendors keep an incident in monitoring for hours or days after the impact ends. It is shown only for vendors that post a monitoring stage; Slack, Azure, AWS, Google Cloud and Better Stack pages don't, so compare them on time to resolution. A vendor posting the same title again within an hour counts as one incident. For backdated incidents, the earlier of the posted and stated start times is used. Median and p95 use the nearest-rank method over incidents that started in the last 90 days and have been resolved.
AWS only lists events that are still open, so an AWS event counts as resolved at the first collection that no longer shows it. That can be up to three hours late, and an AWS event that opens and closes between two collections is missed. Better Stack pages publish only incidents that are still open, so for those vendors only incidents open at a collection are recorded. Instatus does not publish severity, so its incidents show impact as not stated. An incident with no update for 14 days is not shown as open.
Upstream providers and knock-on incidents
An incident names an upstream provider when its title or updates mention AWS, Google Cloud, Azure, Cloudflare, Akamai, GitHub, OpenAI or Anthropic by name. A knock-on incident names a provider and starts while that provider has its own incident, or within 30 minutes of it. Only the first 24 hours of a long provider incident count. Naming a provider is not proof that the provider caused the incident, and vendors that never say which provider failed are missed.
Failure modes and root causes
Each incident resolved in the last 120 days is read by deepseek/deepseek-v4.1-flash, which picks one failure mode and one root cause from fixed lists, plus a confidence level. It only sees the incident's title, components and updates. When the vendor describes only symptoms, such as errors or slowness, the failure mode is recorded as not enough information, and when it does not say why something broke, the root cause is recorded as not stated, rather than guessed. The labels are a model's reading of short, vendor-written text, so treat them as a first pass, not an audit.
The failure modes are our own, version 0.3. Each one maps to the closest family in StackGen's State of Reliability 2026 taxonomy, so totals can be compared with theirs.
| Failure mode | StackGen family |
|---|---|
| A provider or third-party service this vendor depends on failed | F1 Network & Connectivity |
| Network, DNS, routing or connectivity failure | F1 Network & Connectivity |
| A zone, region or data center became unavailable | F1 Network & Connectivity |
| CDN or edge layer failed or served bad content | F1 Network & Connectivity |
| Traffic surge or denial-of-service attack | F1 Network & Connectivity |
| Exhausted memory, disk, CPU, queues, connection pools or quotas | F2 Capacity & Resource |
| A code release introduced the failure | F3 Change-Induced |
| A configuration change caused the failure | F3 Change-Induced |
| A schema or data migration caused the failure | F3 Change-Induced |
| Data delayed, stale, lost or corrupted, or needing replay after recovery | F4 Data & State |
| Orchestration, control plane, service discovery or load balancing failed | F5 Platform & Control Plane |
| AI model returned degraded, wrong or empty output (not errors or timeouts) | F6 AI-Specific |
| Login, tokens, certificates or credentials failed | F7 Security & Auth |
| Security incident or emergency response to a vulnerability | F7 Security & Auth |
| Hardware, power, cooling or another physical failure | F8 Hardware |
| The text does not say enough to tell |
What this data cannot tell you
Status pages are written by the vendors themselves. Some post every blip and some only post large outages, so a high count can mean an honest vendor rather than an unreliable one. There is no usage denominator, labels drift over time, and history before collection started is limited to what each feed still shows.
Reuse
The incident dataset is licensed CC BY-NC 4.0: free to reuse for research, journalism and other non-commercial work, with credit to sevanalysis. Commercial use needs a separate license: write to hello@sevanalysis.com. It contains the vendor, title, impact, times, components, the providers an incident names, the failure-mode and root-cause labels, and a link to the source. Update text is not included and is quoted on this site only in short excerpts; the full text stays on the vendor's page.
Email addresses from the signup form are used only to send the quarterly report and are never shared. Reply to any report to be removed.