In defense of GitHub’s poor uptime: bad, but not a total apocalypse

What set people off

It has been reported that a community tracker called “The Missing GitHub Status Page” shows GitHub at roughly 89.43% uptime over the last 90 days — a number that, on the face of it, implies more than 2.5 hours of downtime every day. Ouch. Developers are angry. Rightly so: when your source control and CI systems hiccup, work grinds to a halt. And yes, GitHub is owned by Microsoft, which only makes the frustration louder. But is the headline number telling the whole story? Not exactly.

The math you didn’t ask for (but should care about)

Four nines — 99.99% — is the industry gold standard. It sounds simple: almost no downtime. But uptime math isn’t always intuitive. If a platform is composed of many independent services, measuring availability by counting any service outage as “GitHub down” will make the aggregate number look far worse than most users’ experience. Consider dozens of features (webhooks, Issues, Packages, core Git ops). If they fail at different times, the pooled uptime collapses even if no single feature is catastrophically unreliable. It has been reported that core Git operations alone were near 98.98% over 90 days — not great, but dramatically different in tone from “zero nines.”

So — F or D?

The takeaway: GitHub’s availability is unacceptably low and deserves critique. But lumping everything into one terrifying stat flattens important nuance. Service isolation is a feature, not a bug; it’s good that a Packages outage doesn’t necessarily break Issues for everyone. That said, near-99% for core Git still means hours of pain for teams. D-tier performance, not an F. People are justified in being upset — but let’s pick our fights based on accurate, useful numbers, not the scariest headline we can cook up.

Sources: evanhahn.com, Lobsters