GitHub Can't Hold Three Nines, and That's Everyone's Problem

GitHub's availability has become a recurring punchline, and The Register put numbers to it: the platform is struggling to maintain even 99.9% uptime — three nines, the baseline that most production services treat as table stakes.

To put that in perspective, three nines means roughly 8.7 hours of downtime per year. Four nines (99.99%) allows about 52 minutes. Most developers would tell you their own services target four or five nines for anything customer-facing. GitHub, the platform that underpins CI/CD pipelines, code review, deployments, and issue tracking for tens of millions of developers, apparently can't clear the bar that a mid-stage startup sets for its API.

The pattern is familiar to anyone who's watched their Actions workflow hang or seen 'git push' timeout during a crunch: GitHub incidents cluster around peak hours, affect core services (not just peripheral features), and the post-mortems read like variations on the same theme — database contention, capacity planning gaps, cascading failures in distributed systems.

Microsoft acquired GitHub in 2018 for $7.5 billion. Since then, the platform has added Copilot, Actions, Codespaces, and a sprawling enterprise tier. The feature velocity has been impressive. The operational maturity has not kept pace. This is a classic platform scaling trap: every new feature adds load paths, failure modes, and integration surfaces. When the infrastructure team is outrun by the product team, availability is what gives.

The real cost isn't the minutes of downtime in an SLA spreadsheet. It's the compounding disruption: a blocked deploy during an incident window, a CI pipeline that needs manual restart, a code review cycle that loses a day. For teams that have built their entire development workflow on GitHub — and Microsoft has spent years encouraging exactly that level of lock-in — each outage is a reminder that they've handed a single vendor the keys to their entire software delivery pipeline.

The alternatives aren't magic bullets. GitLab self-hosted gives you control but adds operational burden. Bitbucket exists but lacks the ecosystem gravity. Gitea and Forgejo are credible for small teams but not enterprise-ready at scale. The honest answer is that most teams are stuck, and they know it.

What should a pragmatic engineering org do? First, stop treating GitHub as infallible infrastructure. Build CI/CD with graceful degradation — local caching of dependencies, artifact mirrors, the ability to push to a secondary remote. Second, track GitHub's actual availability against your own deployment windows. If their downtime clusters overlap with your release cadence, that's a scheduling risk you should quantify. Third, pressure Microsoft through enterprise contracts. SLA credits are the only language cloud vendors hear.

Three nines used to be the floor. For the platform that owns the developer workflow, it should be an embarrassment.