GitHub's Reliability Report Card: 1,125 Incidents and Counting

A new side project, Is GitHub Cooked?, does what GitHub's own status page doesn't: it turns years of incident history into a filterable, service-level reliability report card. The site pulls GitHub's public incident data going back to March 2016 and lets you slice it by service, severity, and time window.

The headline numbers are sobering. GitHub has logged 1,125 incidents since 2016, averaging 24 per month over the last three months (down 5% from the previous quarter). The longest stretch without an incident was just 8 days, ending December 31, 2025. February 2026 was the worst month on record with 37 incidents.

Copilot and Actions are the weak links

The service availability table (trailing 3 months) tells a clear story: the AI-heavy and CI/CD workloads are the most fragile. Copilot sits at the bottom with 97.93% uptime (7 days 13 hours of downtime), followed by Actions at 98.21% (6 days 12 hours). Pull Requests, Search, and Webhooks round out the bottom five.

At the other end, core repository operations are far healthier: Repositories, Gists, and the Dashboard all sit above 99.9%, with Dashboard, Discussions, Docs, and Mobile at a perfect 100%.

Severity and resolution patterns

Severity breakdown shows that 81% of incidents are classified as Minor, 17% Major, and only 2% Critical. That's a lot of noise, but the cumulative effect matters: even minor incidents can break CI pipelines or block PRs.

The worst day for incident count was February 9, 2026, with 7 incidents. The worst day for raw downtime was April 16, 2025, with 1 day 2 hours of accumulated downtime. Wednesdays and Tuesdays are the most incident-prone days, while weekends are relatively quiet.

What this means for your SLOs

If you're building on GitHub Actions or Copilot, your own reliability narrative is tied to GitHub's. A 98% uptime on Actions means you need to design for intermittent failures—retries, fallback runners, and alerting that doesn't page you for every blip.

The site's value is in making these tradeoffs explicit. You can filter by the services you actually depend on and set your own severity thresholds, so you're not arguing with a colleague who only cares about git operations while you're fighting a Copilot outage.

It's a reminder that "GitHub is down" is rarely a single event—it's a spectrum of service-specific failures that hit different teams differently.