You know the feeling. You’re mid-deploy. The CI pipeline is humming. Then — red. GitHub Actions is down. Again. You check the status page, and there it is, the phrase that’s becoming a running joke in your Slack channel: “degraded availability.”
It’s Thursday. Of course it is.
One commenter on the latest incident put it perfectly: “So, it’s a normal Thursday?” That’s not gallows humor anymore. That’s muscle memory. And that should terrify anyone who builds software for a living.
This was incident number six in August. Six. In one month. We’re not talking about a scrappy startup learning to scale. We’re talking about a platform owned by Microsoft — you know, the company that literally runs one of the largest cloud infrastructures on Earth. The same Azure backbone that powers governments and Fortune 500s. And somehow, they can’t keep a git server and a CI runner online for a full week.
When your reliability is a meme, your reliability is a problem.
GitHub’s go-to excuse is predictable by now: AI workloads, scaling challenges, unprecedented growth. It sounds reasonable until you remember who owns them. Microsoft didn’t buy GitHub in 2018 for $7.5 billion because they needed a version control tool. They bought it because 40 million developers lived there. Developers who, once locked into Actions, Packages, Codespaces, and the entire ecosystem, aren’t going anywhere.
And that’s the twist nobody wants to say out loud.
Microsoft doesn’t need GitHub to be reliable. They need it to be indispensable. There’s a difference — and it’s the difference between a product and a hostage situation.
Think about it. If GitHub were a cost center bleeding money every time it went down, the outages would stop. Executives would descend, war rooms would form, and someone’s head would roll. But when your users are captive, when switching costs mean rewriting entire pipelines, retraining teams, and abandoning years of integrations — an outage isn’t an emergency. It’s an acceptable loss on a spreadsheet.
Captive loyalty doesn’t earn investment. It earns indifference.
That’s why the speed of GitHub’s reputation collapse is, as one developer noted, “fascinating.” Not surprising. Not alarming. Fascinating. Like watching a building slowly settle into its own foundation. You know how it ends, but you can’t look away.
Here’s what makes it sting: developers didn’t just use GitHub. They loved it. It was the one platform that felt like it was built by people who understood us. The commit graph, the pull request flow, the open-source community — it had soul. Microsoft bought that soul, and now they’re spending it down like depreciating capital.
Every outage erodes something no status page can measure: the emotional contract between a platform and the people who made it their home. You can fix infrastructure. You can’t fix the slow, quiet death of trust.
So what do you do? You probably keep using GitHub. We all do. Because the alternatives require effort, and we’re tired, and the deploy still needs to go out. But maybe — maybe — you start keeping that local backup a little more carefully. Maybe you start eyeing GitLab a little more seriously. Maybe you stop treating GitHub like infrastructure and start treating it like what it’s become: a vendor you can’t leave but shouldn’t trust.
The most dangerous lock-in isn’t technical. It’s the kind where you stop believing things will get better and start settling for them not getting worse.
GitHub isn’t dying because of AI. It isn’t dying because of scale. It’s dying because the company that owns it has calculated exactly how much reliability they can withhold before you finally leave — and they’ve decided that number is higher than you think.
The question is whether they’re right.
FAQ
Q: Isn't this just a scaling problem that comes with growth?
A: No. Microsoft owns Azure — one of the largest cloud infrastructures on Earth. If they wanted GitHub to be rock-solid, they have the engineering firepower to make it happen. The outages persist because reliability isn't prioritized, not because it's technically impossible.
Q: What should developers actually do about this?
A: Stop treating GitHub as infallible infrastructure. Maintain local backups, diversify your CI/CD where feasible, and start evaluating alternatives like GitLab or self-hosted Gitea before you're forced to in a crisis. Treat vendor lock-in as a risk, not a convenience.
Q: Is Microsoft deliberately letting GitHub degrade?
A: Not deliberately — indifferently. That's worse. When users are captive, the incentive to invest in reliability disappears. Microsoft doesn't need GitHub to be great. They need it to be un-leavable. Those are fundamentally different goals.