Back to Blog

Incident Scorecards

How well do organizations handle incidents?

In this series of posts, I’ll deep dive into how high-profile incidents are handled at some of the largest companies in the world and score them on a number of different dimensions. I’ll leverage publicly available information (status pages, blog posts, documentation, etc.). My goal is to shed light on details that indicate great operational excellence practices and areas that need improvement. I do not wish to bash anyone. There are real people who are doing their best to prevent these issues from occurring and also put out fires when they happen. It is a stressful job that doesn’t get the credit it deserves. Software engineers, SREs, EMs, and other technical leaders take the brunt of the public’s criticism when these things occur. When systems are healthy, no one gives them a pat on the back.

The scorecards

Anthropic, xAI, OpenAI · September 3, 2026

ChatGPT, Claude, Grok outages: achieving multi-provider AI high availability in a capacity-constrained world

On September 3, 2026 Claude, Grok, and ChatGPT all failed within two hours. A three-company incident scorecard, and what it means for multi-provider AI.

Anthropic
3.8 / 10
xAI
3.7 / 10
OpenAI
7.5 / 10

GitHub · August 17, 2026 · 7h 47m

GitHub incident: autoscaling misconfiguration and retry storm

GitHub's August 17 outage took out Pull Requests, Actions, and Copilot for nearly eight hours. An incident scorecard on how they detected, communicated, and recovered.

5.3 / 10

How the scoring works

Each dimension is scored 1–10, or marked N/A where it does not apply — a deployment-rollback score means nothing for an incident no deployment caused. The headline incident score is the unweighted mean of the dimensions actually graded; N/A entries are excluded rather than counted as zero, so sitting a dimension out never drags a score down.

9-10Excellent7-8Good4-6Fair1-3Poor
The twelve dimensions of an incident scorecard
DimensionWhat it measures
Detection
Time-to-detect (TTD)The time between the impact starting and when the first responder sees an alert fire.
Detection sourceThe source of the notification that indicated there was a problem. This can be external customers, internal alerts, or internal employee discovery, among other sources.
Communication
Status page updatesMeasures the information quality, clarity, and frequency of posts to the public status page for customers to follow along with.
Remediation
Time-to-mitigate (TTM)The time between the start of impact to when that impact is mitigated to some degree.
Time-to-resolve (TTR)The time between the start of impact to when that impact is fully addressed.
Blast radius reductionThe degree to which the impact was isolated to only a subset of customers/requests/etc.
Automated remediationThe level of automation that was self-healing during the incident and did not require manual intervention.
Rollback vs. RollforwardThe speed at which a deployment-related issue was resolved. Applicable if there was a deployment that caused the issue or whether a change needed to be deployed to production to remediate the issue.
Risk-to-Reoccur
Prevention mechanismsThe breadth and depth of guardrails put in place to prevent a similar issue from happening again in the first place.
CI/CD test coverageThe amount of testing (unit, integration, e2e, performance, chaos, etc.) conducted as part of the CI/CD process.
Root-cause Analysis
Time-to-root-cause (TTRC)The amount of time since the start of impact until the root cause is fully understood.
Root cause transparencyThe degree to which the root cause is explained in sufficient detail.