Summary: On April 28, 2026, Ghostty developer and HashiCorp co-founder Mitchell Hashimoto announced that Ghostty is leaving GitHub after a month in which almost every day had an outage that interfered with his work. He distinguishes Git, which still works offline, from unreliable GitHub services such as issues, pull requests, and Actions. No destination is named yet, but a read-only GitHub mirror will remain.
On April 28, 2026, Mitchell Hashimoto — the developer behind the Ghostty terminal and a HashiCorp co-founder — announced on his blog that Ghostty is pulling out of GitHub. He registered in February 2008 as GitHub user #1299 and has used the platform daily for 18 years. Git is not what drove him away; it is the services around it — issues, pull requests, and Actions — failing one after another. Over the past month he kept a journal, writing an “X” beside each day a GitHub outage damaged his work, and his tally read “Almost every day has an X.” The post raced onto the Hacker News front page, gathering 3,521 points and 1,051 comments to become the developer world’s story of the week.
Why it carries weight: GitHub underpins the delivery pipeline for much of the industry — pull request flows, CI, and project management all run on it. When the maintainer of a top-tier open source project walks away publicly and names reliability as the reason, it warns everyone building on the platform: once the core services wobble, delivery stalls with them.
A Journal Filled with X Marks
Hashimoto walked through the log from his past month: any day a GitHub outage interfered with his work got an X, and “Almost every day has an X.” The day he published, a GitHub Actions failure stopped him from reviewing pull requests for close to two hours; a separate April 28 incident knocked pull requests out entirely, traced to an Elasticsearch problem. His read is blunt: a place that shuts you out for hours every day is “no longer a place for serious work.”
Git Itself Never Failed
The boundary he insists on matters: Git was not what failed. Distributed version control runs without a network by design; what keeps breaking is the layer GitHub makes money from — issues, pull requests, and Actions, the SaaS services on top. His argument is not “abandon version control” but “outsourcing your collaboration layer to a vendor whose reliability is slipping gets more expensive every quarter.” He is just as open about the personal side: “Because GitHub is failing me, every single day, and it is personal. I want to ship software and it doesn’t want me to ship software.”
A Destination Not Yet Picked
This exit, unlike most headline migrations, names no destination. Hashimoto says he is “still in discussions with multiple providers (both commercial and FOSS),” with details due over the coming months. Three points are settled: the move will proceed “as incrementally as possible”; a read-only mirror will remain on GitHub at its current address; and his personal projects stay put for now, because Ghostty is where he, the maintainers, and the community take the hardest hit. He has also apologized for his recent public criticism of GitHub — he says he has “hurt people’s feelings” — but a return would have to be “predicated on real results and improvements, not words and promises.”
One SaaS Under the Whole Pipeline
The Register’s reporting adds backdrop: fears after Microsoft’s purchase of GitHub “largely proved unfounded” — yet the platform’s worsening stability coincides with Microsoft’s pivot toward AI. Over the same stretch the outlet also documented forced CLI telemetry and Copilot halting sign-ups under capacity strain. For product teams the takeaway is structural: a development pipeline is, at bottom, a SaaS supply chain, and any outage in PR review, CI, or issue tracking is billed straight to engineer-hours — a bill that shows up on no ledger.
The Audit to Run Before a Move
Step one, prove the Git workflow runs with no network at all: local clones and bundle backups are the floor any migration plan must clear. Step two, write out the platform lock-in — Actions workflows, issue templates, bot integrations, SSO. That list holds the real cost of a move; the code always transfers with the least friction. Step three, settle the incident plan early: if pull request review goes dark for two hours tomorrow, what is the fallback? Most teams should stay put, but every team should keep a “GitHub is unavailable tomorrow” playbook. The idea most worth stealing is his journaling — recording, day after day, the actual damage each outage causes — which turns platform risk from diffuse worry into a number you can act on.