GitHub reliability becoming a real conversation again
A GitHub incident affecting pull requests, issues, git operations, and API requests is generating the usual round of 'I'm done with GitHub' comments on HN, but also some sharper observations. The incident page being linked while the actual system is down, the pattern of outages affecting exactly the workflows that AI coding tools depend on heavily, and the comparison to GitLab are all surfacing again. This is not the first such thread; it is a recurring one that has grown sharper in tone over the past year.
The pattern here is that GitHub's reliability has become a genuine operational risk for teams that have built tightly coupled CI/CD pipelines, agent workflows, and API integrations on top of it. When GitHub goes down, the effect is no longer just 'we can't push code for an hour'. It now cascades into broken agent loops, failed deployments, and lost context in AI-assisted workflows. The dependency has deepened while the tolerance for downtime has dropped.
The counterpoint is that GitLab and self-hosted alternatives have their own pain, and most teams will absorb the outages rather than migrate. But the conversation is genuinely shifting from annoyance to risk calculus.
So what?
If your production deployment pipeline or your AI coding workflow has a single hard dependency on GitHub with no fallback, that is worth addressing. At minimum, having a local mirror strategy and knowing how long you can operate without GitHub access is the kind of resilience planning that most small teams skip until they are sitting idle during an outage.