By ByteBot
Mitchell Hashimoto, co-founder of HashiCorp and GitHub user number 1,299, announced on April 28 he’s moving his Ghostty terminal emulator off GitHub after 18 years of daily use. His reason: “This is no longer a place for serious work if it just blocks you out for hours per day, every day.” Hashimoto joined GitHub in February 2008, used it to build Vagrant and Terraform, and stayed loyal through nearly two decades of change. When an 18-year platform evangelist walks away, it signals a crisis.
The Merge Queue Bug That Silently Corrupted Code
On April 23, 2026, GitHub’s merge queue silently corrupted 2,092 pull requests across 658 repositories. Developers clicked “merge,” everything looked successful, and GitHub reported no errors. However, code from previously merged pull requests was invisibly reverted by subsequent merges. The bug ran for 3 hours and 38 minutes before customer reports forced GitHub to investigate. Their own automated monitoring never caught it.
The root cause: a new code path adjusted merge base computation for merge queue ref updates. This code path was supposed to be gated behind a feature flag for an unreleased feature, but the gating was incomplete. Consequently, when merge groups contained multiple pull requests using squash merge, GitHub produced an incorrect three-way merge. Changes disappeared without warning.
Silent corruption is worse than outages. When Actions goes down, developers know to wait. When merges silently fail, developers trust broken systems until customer complaints surface the damage. GitHub acknowledged the incident on April 28 but admitted detection came through users, not their own reliability infrastructure. That’s a trust gap.
Systematic Failures: “Almost Every Day Has an X”
Hashimoto didn’t leave over one bug. Instead, he left after tracking daily GitHub outages in a journal, marking an X for every day an outage negatively impacted his work. The result: “Almost every day has an X.” On April 27, the day before his announcement, he spent two hours blocked from reviewing pull requests due to a GitHub Actions outage. That same week saw three significant failures in five days: the merge queue corruption, a search system collapse, and a remote code execution vulnerability in the core git push path.
The statistics back up his frustration. Between May 2025 and April 2026, GitHub experienced 257 incidents with 48 classified as major outages. Additionally, GitHub Actions alone had 57 outages and 16 major incidents in that period. January and February 2026 each recorded 8 outages. At one point in 2025, GitHub’s uptime fell below 90 percent—far short of the 99.9% Service Level Agreement promised to Enterprise Cloud customers.
These aren’t minor hiccups. In one March incident, 95% of GitHub Actions workflow runs failed to start within 5 minutes, with an average delay of 30 minutes. On February 2, hosted runners went offline for hours, queueing and timing out jobs while developers waited. When deployment pipelines freeze, entire teams stop shipping. When pull request reviews block, collaboration halts. GitHub promised availability; it delivered systematic disruption.
Platform Monopoly Meets Reliability Failure
Even after deciding to leave, Hashimoto hasn’t chosen a destination. He’s evaluating commercial and open-source alternatives, plans to maintain a read-only GitHub mirror during transition, and admits his personal projects will stay on GitHub for now. This hesitation exposes the real problem: GitHub’s monopoly creates a single point of failure for global software development. Moreover, when 90% of open-source projects live on one platform, reliability failures trap millions of developers.
Alternatives exist—GitLab, Forgejo, and Gitea—but none offer GitHub’s ecosystem. Repository migration is straightforward; all platforms support importing from GitHub with issues, pull requests, and wikis intact. CI/CD migration is harder. GitHub Actions workflows need rewriting unless you choose Forgejo, which maintains syntax compatibility. Nevertheless, the real barrier is the ecosystem: community, stars, forks, packages, integrations. Network effects built over 15 years don’t transfer between platforms.
In one study analyzing student developers, 237 out of 238 used GitHub for open-source contributions. Only one managed to avoid it. When a platform reaches that level of concentration, it stops competing for quality and starts extracting from dependency. Did lack of competition make GitHub complacent about reliability? The merge queue bug wasn’t a capacity problem—it was a code quality failure. Incomplete feature flag gating and insufficient test coverage are process issues, not scaling challenges.
The AI Scaling Context (Not an Excuse)
GitHub attributes some reliability issues to explosive growth from AI-powered development tools. In October 2025, they planned a 10X capacity increase. By February 2026, they realized they needed 30X scale. Since December 2025, agentic workflows from tools like Copilot, Claude Code, and Cursor have accelerated repository creation, pull request activity, and automation workloads. Furthermore, GitHub set records: 90 million pull requests merged, 1.4 billion commits, 20 million new repositories per month.
The scaling challenge is real, but it doesn’t excuse silent failures. Capacity constraints cause slowdowns and timeouts—understandable growing pains when infrastructure struggles to keep up with demand. However, code quality bugs that revert merged changes without detection? That’s a different failure class. GitHub’s April 28 response promised “availability first, then capacity, then new features” as the new priority order. They pledged to improve service isolation, eliminate single points of failure, and provide greater transparency. These are necessary commitments, but they address symptoms without examining whether monopoly status bred institutional complacency.
What Comes Next
The Hacker News discussion about Hashimoto’s departure drew 315 points and 189 comments, revealing a divided community. Some sympathized: “I can relate—GitHub has been unreliable.” Others defended scaling challenges: “No platform is perfect at this size.” Meanwhile, many questioned where Hashimoto would go, acknowledging the lack of viable alternatives.
Ghostty, with 45,000 GitHub stars and roughly 1 million weekly macOS downloads, represents a significant migration test case. If Hashimoto successfully relocates a major open-source project with active development and a large community, it demonstrates that leaving GitHub is possible. Conversely, if he struggles or returns, it confirms the lock-in problem. Either way, his 18-year loyalty ending sends a message: reliability failures have consequences, even for monopoly platforms.
GitHub promised to publish root cause analyses for April’s incidents and committed to prioritizing availability. The question is whether promises translate to sustained improvement or temporary PR damage control. Hashimoto’s journal marked almost every day with an X. How many more developers are quietly tracking the same pattern, waiting for one more outage to push them past their breaking point?
