Exposed on Main: GitHub's Vanishing Uptime and Microsoft's AI Distraction

A previously, I wrote about the importance of keeping your fundamentals covered even as AI tools transform how we ship software. The point was simple. The tools are powerful. The future is real. But you ship with protection. You keep the basics working. You do not let the excitement of what is new distract you from what is necessary.
GitHub just became the case study I did not want to write.
The numbers are not subtle. GitHub promises 99.9% uptime in their service level agreement. Independent tracking tells a different story. The unofficial GitHub status page, built because the official one does not publish aggregate uptime at all, puts the real figure somewhere around 87% and still falling. The official status page shows individual services hovering above 99%, a number that anyone who uses GitHub daily knows does not match reality. The numbers are cherry-picked, and the aggrieved users who built the unofficial tracker did so because they had no other way to know whether the platform was working.
In one week this April, two major incidents hit the platform. First, a search outage cascaded through the system, making pull requests and issues invisible for hours for a large number of users. The counters showed open PRs, but clicking through returned nothing. The data was there, but the search layer that surfaces it had collapsed. Days earlier, a quieter but more alarming incident had occurred. GitHub's merge queue, the automated system that merges approved pull requests, began silently reverting code on customer main branches. When a merge group contained more than one pull request and used the squash merge method, the resulting commit did not include changes that had landed on the main branch while the feature branch was open. Code disappeared. The company's own operations lead characterized the incident as affecting roughly 0.07 percent of merges that day, about three thousand pull requests out of four million. A small percentage. Unless yours was one of them. Then it was everything.
What makes these incidents land differently is the context surrounding them. The person who leads GitHub stepped down months ago. The position was never backfilled. There is no captain. The operations lead reports into a larger corporation instead of a GitHub chief executive. The structure looks like a restaurant where the head chef has walked out and nobody got hired to replace them. The line cooks are talented. The waitstaff is excellent. The sommelier knows every vintage. But without someone running the pass, calling the orders, and making sure every plate that leaves the kitchen is correct, things break. Some dishes never leave the kitchen. Some go out wrong. The diners notice.
Meanwhile, GitHub has shipped an extraordinary number of AI features in the past eighteen months. Copilot workspace. Copilot agents. Spark models. Copilot code review. Copilot in the command line. These are not small side projects. They represent a massive allocation of engineering resources toward the future of AI-assisted development. I believe AI is the future. I have said it before and I mean it. The tools are getting better. The capabilities are real. But none of that matters if the platform those tools run on cannot reliably serve a pull request. You do not build AI features on top of a platform that keeps falling over. You fix the platform first, and then you enhance it. Microsoft appears to be doing the reverse.
This would be an academic conversation about uptime percentages if real projects were not leaving. Mitchell Hashimoto, one of the earliest GitHub users, who joined the platform in February of 2008 as user number #1299 and has opened it almost every day for eighteen years, recently announced that his team is moving Ghostty off GitHub entirely. He kept a journal marking every day a platform outage impacted his ability to work. Almost every page has a mark. The platform that once made developers happy, that he opened during honeymoons and late nights after breakups, has become the thing that actively prevents him from shipping. In his own words, he wants to be there, but the platform does not seem to want him there.
GitHub is not just a website. It is infrastructure. It holds the code that runs the internet. When it goes down, work stops. When it silently corrupts merges, trust dissolves. When the company that owns it treats it as a division of something larger rather than a platform that must work, the incentives shift away from the people who depend on it every single day.
The lesson here is the same one I keep returning to. Ship with protection. Keep the fundamentals covered. AI is not the problem. Neglecting what already works in pursuit of what comes next is the problem. If you cannot keep the kitchen running, no amount of new menu items will save you.


