GitHub User #1299 Just Left. The Reliability Numbers Explain Why.

Mitchell Hashimoto, GitHub user number 1299, joined in February 2008. He opened GitHub every single day for 18 years. He built Vagrant partly because he wanted a job there. Then on April 28, 2026, he announced Ghostty, his open source terminal emulator, is leaving the platform.

Not because of a policy. Not because of a competitor. Because GitHub stopped working reliably enough to ship software on.

That sentence should land harder than it probably does.

The Receipts

Mitchell kept a journal for a month. An X on every date where a GitHub outage blocked his work. Almost every day had an X.

This is not an isolated feeling. GitHub’s own availability reports are public. In February 2026, six incidents caused degraded performance. On February 9 alone, Actions, pull requests, notifications, and Copilot all went down simultaneously. The multi-service disruption lasted nearly four hours, with Copilot policy propagation failures persisting more than 15 hours into February 10.

In March 2026, four more incidents. On March 3, github.com request failures peaked at 40%. On March 5, 95% of GitHub Actions workflow runs failed to start within 5 minutes, with an average delay of 30 minutes. The cause: a Redis configuration change pushed to production without catching the routing error it introduced.

GitHub’s unofficial status reconstruction showed uptime dropped below 90% at one point during 2025. For context, three nines (99.9%) means about 8.7 hours of downtime per year. Below 90% is 876 hours. That is over 36 full days.

And then on April 27, the day before Mitchell published this post, a large Elasticsearch-related outage hit. He notes the timing was coincidental. The decision had been building for months.

What Actually Breaks When GitHub Goes Down

The “Git is distributed” response misses the point entirely.

Git itself never went down. The issue is everything built on top of it. Issues, pull requests, Actions, CI/CD pipelines, code review workflows, Dependabot, Pages, Codespaces. When GitHub degrades, it does not degrade quietly in one place. It degrades across all of those surfaces simultaneously, because they share infrastructure. The February 9 incident took out Actions, PRs, notifications, and Copilot at the same time. There is no partial GitHub.

For a project like Ghostty, with active maintainers doing real PR review on a daily basis, two hours of unavailability is not an inconvenience. It is lost work that cannot be recovered. Multiply that by almost every day for a month and you have a project that cannot function on its current host.

The Shift That Is Already Happening

Ghostty is not an isolated case. The move away from GitHub has been building quietly, and it is picking up speed.

Individuals and open source communities have been moving to Codeberg, Forgejo, Sourcehut, and self-hosted setups. The revived Dillo browser project moved after losing its domain and archives, with its maintainer noting that centralizing everything on GitHub creates its own category of risk.

Forgejo, the community fork of Gitea governed by a German non-profit, now ships GitHub Actions-compatible CI/CD, has a first-class GitHub migration flow that brings over issues, PRs, labels, milestones, and releases, and runs on hardware you own. Its roadmap includes ActivityPub-based repository federation, which is a direction GitHub is not moving in at all.

None of these alternatives match GitHub’s network effects. Discovery, stars, forks, the social layer, the hiring signal. That moat is real and it is not going away this year. But moats erode when the core product stops working reliably enough to justify staying.

What This Actually Signals

GitHub is the infrastructure layer for most of open source. When that layer becomes unreliable, the cost does not show up as one big visible failure. It shows up as a journal with an X on almost every page.

The projects that will move first are the ones with active maintainers and strong community pull. Projects where the maintainer has enough credibility to bring contributors with them and enough technical capacity to manage a migration. Ghostty fits that profile exactly.

Mitchell has been explicit that his personal projects stay on GitHub for now. This is not a rejection of the platform’s history or what it meant. It is a practical decision made by someone who needed to ship software and kept getting blocked. He tried to give it time, kept a journal to be fair about it, and the data pointed one direction.

The platform that shaped an entire generation of developers is struggling to hold sub-three-nines reliability while simultaneously pushing Copilot as its primary growth story. Those two things are in tension, and serious builders are starting to notice.

Mitchell has not announced where Ghostty is going yet. He is still in discussions with multiple providers, both commercial and open source. The read-only mirror stays on GitHub. The rest of the project is leaving.

If you are building something that depends on GitHub infrastructure, you already know what happens when it goes down. The question is whether you have a plan for when it goes down again tomorrow.

Sources:

• Ghostty Is Leaving GitHub, Mitchell Hashimoto
• GitHub Availability Report: February 2026
• GitHub Availability Report: March 2026
• GitHub Appears to Be Struggling with Measly Three Nines Availability, The Register
• Why Smart Engineers Are Leaving GitHub for Forgejo, Tenotes
• Self-Host Gitea or Forgejo: 2026 Guide, Danube Data