The gravity problem
SimonGitHub has had hundreds of incidents since January 2025. In February 2026, thirty-seven in a single month. In July, a DNS misconfiguration took the site down for over two hours. In August, Actions and Pages were out for nine. Actions has been the hardest-hit service, with an incident most weeks of 2026.
These are not signs of a bad engineering team. They are signs of a service that accumulated more gravity than any single service was meant to have.
GitHub hosts over 600 million repositories and serves more than 180 million developers. Most of the world’s hosted source code lives on one service. That service runs one of the largest codebases ever built and handles a growing population of AI agents that both build on it and consume it. The infrastructure migration to Azure started in October 2025. Their CTO said they need to build for thirty times their current scale. That is honest, and it is a hard problem, and it will take years.
In the meantime, the outages keep coming. Not because anyone is doing a bad job, but because the job is structurally too large.
This is the same pattern as email consolidating into Gmail, or compute consolidating into AWS. When a service becomes the default, the remaining ecosystem builds around the assumption that it is always there. CI pipelines, deployment hooks, dependency bots, code review tools, AI coding agents. All of them assume GitHub is reachable. When it is not, everything downstream stops.
The answer is not switching from one large host to another. That trades one single point for a different one. The structural answer is diversity: more services, smaller, interoperable through federation and open protocols, so that no single outage takes the floor out from under everyone at once.
Git already works this way at the protocol level. Every clone is a full copy. A remote is an address, not a contract. Nothing in Git requires that all copies live in same place, or in a single place. But source code is the easy part. The hard part is everything else: CI pipelines, deployment hooks, dependency bots, code review, and maybe most importantly human and processes and workflows. That is what stops when GitHub goes down, and that is where interoperability matters most.
This is also where things are getting better. For example, Forgejo Actions implements the same workflow syntax as GitHub Actions. The same .github/workflows/ files run on both. A repo can contain host-specific overrides without forking its CI configuration. The gap between “my code is mirrored” and “my CI still works” is smaller than it used to be.
What that looks like in practice depends on the team. Some will move their repos to a different host entirely. Some will keep GitHub as their primary and mirror to a second host for redundancy. Some will start with a mirror and move over time as they build confidence. All of these reduce the blast radius of a single-host outage.
On Codebahn, mirroring a GitHub repo takes one checkbox during import. The mirror syncs on a schedule, stays browsable, and keeps serving if GitHub goes offline. If an outage lasts long enough that you need to push, you convert the mirror to a regular repo. Your .github/workflows/ files run on Codebahn’s EU runners. When GitHub comes back, you push your changes there too. Or you don’t, and Codebahn becomes your primary. Either way, the code is yours and the decision is yours.
The next GitHub outage is not a question of if. The question is what your team does when it happens.