GitHub's downtime is bad, but uptime numbers can be misleading. It's not as bad as it looks; more like a D than an F.

Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

GitHub's reported 89.43% uptime over 90 days sounds alarming, but the aggregate number is misleading. Because GitHub tracks ten separate services (Git operations, webhooks, Issues, etc.), any single-service outage counts against the total even if other services remain healthy. Well-isolated services that fail independently actually produce worse-looking aggregate uptime numbers than tightly coupled services that fail together. Looking at individual components, core Git operations had ~99% uptime over the same period. The post argues GitHub's reliability is more like a 'D' than an 'F', and that the 'zero nines' framing is unfair — though GitHub's uptime is still genuinely below acceptable industry standards.

In defense of GitHub's poor uptime

There are better reasons to dislike GitHub

Just look at uptime BEFORE and AFTER github was bought by microslop. Even if we look not at uptime but at ui side it degraded significantly in quality

Open thoughts:
<ul>
<li>if global downtime is defined by the cumulative downtime of all services, should uptime be computed the same way to make it “fair”?</li>
</ul>
Example: Service A down 1 day out of 10 days, Service B down 2 days out of 10 days. It wouldn’t be 3 days unavailable out of 10, but 3 out of 20 days.
<ul>
<li>
Indeed, having a distributed architecture means that if 1 service is down, it doesn’t mean the dozen others are. So, does it mean that the standard for downtime / uptime computations is outdated and not fit for multi-services architectures?
</li>
<li>
Instead of the naïve 1st suggestion I made, would having a weighting on the services based on their respective importance and criticality in the global solution be fairer?
</li>
</ul>