GitHub's Reliability Worsens as Developers Vote With Their Repos

For engineers who build on GitHub, the platform's reliability has become a persistent background anxiety. The numbers, now compiled by a community-run tracker at isgithubcooked.com, paint a stark picture: since March 2016, GitHub has recorded 1,125 incidents. Over the last three months, the platform averaged 24 incidents per month — a 5% decrease from the prior period, but still high enough that the longest incident-free streak since tracking began was a mere eight days, ending December 31, 2025. February 2026 was the worst month on record with 37 incidents.

These aren't just abstract metrics. On August 26, 2026, GitHub acknowledged a disruption affecting some services, posting on its status page that it was "investigating reports of impacted performance" (GitHub Status). For developers whose CI/CD pipelines, code reviews, and deployments depend on GitHub being available, each incident translates to blocked work, delayed releases, and eroded trust.

That erosion is now visible in developer behavior. In a widely shared blog post titled "Bye, Bye GitHub," a longtime user detailed their departure after 14 years on the platform. "I cannot believe how the software development industry managed to do this," they wrote. "GitHub has the best developers, best engineers, best LLMs, but this is the summary we have." The post points to the same tracker data and argues that for a profit-making company — one that has aggressively used public code to train AI models — the reliability record is unacceptable. The author moved all private repositories to a self-hosted Forgejo instance and cancelled their Copilot subscription (Hacker News).

This is not an isolated sentiment. The tracker's creator notes that "everybody's reliability narrative is a function of the services they depend on and the 9's they expect," and built the site so developers could filter incidents by service and severity. The implication is clear: GitHub's default status page may not surface the granularity that production engineers need to assess risk.

For founders and engineering teams, the calculus is shifting. Self-hosting Git infrastructure — via Forgejo, Gitea, or GitLab — introduces operational overhead but eliminates dependency on a single vendor whose incident rate has been climbing. The question is whether GitHub will treat reliability as a competitive moat or as a cost center. So far, the data suggests the latter.

Independent verification of GitHub's internal root-cause analyses remains scarce. The company publishes post-incident reports for major outages, but the sheer frequency of smaller disruptions suggests systemic issues — possibly related to database scaling, deployment practices, or the complexity of their multi-tenant architecture. Until GitHub addresses the underlying causes, developers will continue to hedge their bets.