A few days ago, Mitchell Hashimoto posted on his personal blog that Ghostty would be leaving GitHub, and it caught a lot of people off guard. GitHub is practically the default choice of the AI era, and Mitchell is not the type who switches platforms after a rough week. He is GitHub user 1299. He signed up in February 2008, has opened GitHub almost every day for 18 years. But in his post he wrote that he was genuinely angry, and the closing line was short: after 18 years, it was time to leave.
Mitchell Is Complaining About One Thing
I went and read the original post in full, because most of what was circulating in shares focused on his emotion — the “even he has had enough” reaction — but what I actually wanted to know was his reasoning.
He is not complaining about the UI, not Copilot, not the product decisions people usually argue about. His complaint is basically one thing: GitHub’s reliability is affecting his basic daily work, specifically, GitHub Actions and the surrounding infrastructure being unstable enough to block him from doing PR review. So he kept a very manual but honest record. Every morning he checked whether a GitHub outage had affected his work that day, and if it had, he marked the date with an X. No dashboard, no beautiful chart, no automated monitoring. Just a row of X marks from an engineer who opened the same tool every day and got blocked by it.
“It is no longer a fun place. I want to stay but it doesn’t want me to stay,” he wrote. That sounds emotional, but I know that feeling. The person who created Vagrant, Terraform, and Vault would not call a technical platform irrationally personal without good reason. That is past mood. I get it.
He Is Not the Only One Feeling This
The next day, Jonas Hietala also published a post saying he was moving from GitHub to Codeberg/Forgejo[12]. And if you go back further, byteiota had already documented eight major GitHub outages across February and March 2026 — GitHub simply did not hit its three-nines SLA for Enterprise customers[11]. Aakash Gupta was even more direct on X: February 2026 alone had 37 incidents, 23% more than before.
Those external counts are context, but the number that stopped me came from GitHub’s own March availability report. On March 5, from 16:24 to 19:30 UTC, 95% of GitHub Actions workflow runs failed to start within five minutes, with an average delay of 30 minutes, and another 10% of runs failed outright with infrastructure errors (my former company went through that chaos too)[3]. When a CI/CD platform’s workflows basically cannot start for most of an afternoon, this is not “wait a little longer.” The PR pipeline gets blocked outright. That day, our team joked we might as well leave early.
Solomon Neas added two more points in his independent analysis[2]. On April 23, a merge queue correctness bug affected 658 repositories and 2,092 PRs, producing incorrect squash merge commits that could overwrite work on the default branch. On April 27, the same day Mitchell wrote his post, Elasticsearch was overloaded for six hours and 15 minutes, and search-backed UIs — including PR lists — could return blank pages. In other words, a green status page does not mean everything is fine.
Why Now?
GitHub did not just launch Actions yesterday. Large open source projects are not new either. So why is the instability suddenly so visible to so many people? Look back at the February availability report[4], a line that was also cited in InfoQ’s coverage[5]: GitHub said load was growing so fast that they needed to design for 30 times their current capacity, with the acceleration mainly coming from agentic development workflows that had risen sharply since mid-December 2025. Of course, GitHub would not say “the AI boom knocked us over.” What they said was scaling challenges, architectural coupling, limitations in handling load — words that sound engineering, and also sound like PR. But layer in the other numbers and a reasonable picture starts to form.
HUMAN Security’s 2026 AI traffic benchmark[6] reports that AI-driven web traffic tripled across 2025. AI scraper traffic grew 597%, agentic AI traffic grew 7,851%. OpenAI alone accounted for about 69% of all AI bot traffic, Meta 16%, Anthropic 11%. That traffic spreads across every corner of the web, but a significant portion ends up hitting GitHub, because training data, real-time search, and agent interaction all depend on code — and GitHub is most people’s first choice, even the platform these AI companies default to recommending.
The more awkward part: GitHub itself launched Agentic Workflows in February[7], letting AI agents run inside GitHub Actions triggered by issues, PRs, and CI events — automatically triaging bugs, writing fixes, running tests, opening PRs. And now this seems to have become part of what is taking them down.
I would not frame this as “AI caused GitHub outages” — that is too simplistic and skips way too much context (in the AI era, we all need to watch our context~ ha). But a few things are clear: external AI traffic is turning GitHub into a high-pressure zone, and GitHub is also loading more agent work into the Actions pipeline itself. The 10X capacity plan got revised to 30X. The car they thought they were chasing suddenly got farther away.
AI Automation?
When Actions blocked Mitchell for two hours, he knew he was waiting. He could get coffee, do something else, write a farewell post. AI agents wired to GitHub Actions usually do not have that judgment.
The standard PR loop for a modern AI agent looks roughly like this: see an issue or a human instruction, write a fix, open a branch, push, open a PR, wait for GitHub Actions to run CI, read the result, revise if necessary, push again, wait again. Every step of that pipeline depends on Actions returning a signal in a reasonable time. When the Actions queue stretches past 30 minutes, the agent times out, then retries, then creates another workflow run. That loop that cannot stop itself feeds pressure right back into Actions’ load.
It gets worse when search-backed UI returns blank pages. Agent list and inspect steps — checking PR state, looking for related issues — get empty results. The agent may not know whether it is seeing “nothing exists” or “I could not retrieve it.” That difference is brutal for an automation pipeline. Humans stop during outages and do something else. Agents keep generating more investigative requests that help bring the system down.
I have run into a similar shape in my own Agent Team work: when the other system starts degrading, Agent still follows the flow and keeps sending requests and spawning child processes. Once that pattern takes hold, the thing that usually collapses is not the other system — it is my own automation, because it stops receiving signal, starts making wrong assumptions, retries, and eventually traps itself in a loop that looks busy but goes nowhere. For teams relying on GitHub Actions for CI, agentic workflows, and PR automation, GitHub is no longer just a stable background git host. It has become a narrow single-lane road inside the pipeline, and on that road, human developers complain and pause when traffic stops — AI agents just keep pressing the accelerator.
What’s Next?
GitHub has already publicly apologized. The CCO’s line, “I’m sorry. The team is going to keep working to make GitHub something you can come back to with real proof”[10] shows GitHub’s sincerity. They have also announced a move toward Azure infrastructure to improve capacity (seriously? Azure?). But Solomon Neas’s framing is right: this is no longer just a capacity problem — it is an engineering debt explosion. Feature flags that failed to contain unreleased code paths. Test coverage that missed multi-PR squash merge cases. No monitoring for merge correctness. No load shedding on Elasticsearch. These problems do not disappear when you add more machines. Adding capacity only delays when it happens. As the system gets larger, traffic grows higher, and AI gets smarter, the interest compounds — the next structural bottleneck is still coming.
Mitchell is an individual developer. He can leave. He can slowly remove dependencies and migrate issues. Enterprise CI, AI agent toolchains, and agentic workflows wired into GitHub Actions cannot walk away that easily. That is why his announcement resonated so widely — many people finished reading and the next question was not “where is he going?” but “where can I go?” (Yeah, where can I go?).
Maybe the next few months will push Codeberg, Forgejo, and self-hosted Gitea into higher visibility. But for teams deeply dependent on AI automation, the real question is not whether to migrate tonight — it is whether, when your PR flow and GitHub Actions are tied to the same cable, you have a Plan B. Do you have a strong enough framework and methodology to navigate these changes? Or are you just optimizing for a Working System that works today? Mitchell’s journal, GitHub’s own 30X number, Solomon’s 90-day Actions uptime of 99.38% — all of it is saying this cable probably will not suddenly become stable anytime soon. It might even snap again.
I do not think anyone expected the first thing the AI wave would force to turn in early would not be GPUs, not models, not the inference costs we talk about every day — but the git host everyone assumed would just be there when they opened their laptop every morning. Looking back: “I want to stay but it doesn’t want me to stay” — I think that is a feeling a lot of people share. Everyone experiences it differently, but the question stays the same: where can I go?
References
[1] Mitchell Hashimoto — Ghostty Is Leaving GitHub
https://mitchellh.com/writing/ghostty-leaving-github
[2] Solomon Neas — GitHub Availability in April 2026: Merge Queue Corruption, Search Collapse, and What the Status Page Misses
https://solomonneas.dev/blog/github-availability-agentic-load-report
[3] GitHub Blog — March 2026 availability report
https://github.blog/news-insights/company-news/github-availability-report-march-2026/
[4] GitHub Blog — February 2026 availability report
https://github.blog/news-insights/company-news/github-availability-report-february-2026/
[5] InfoQ — GitHub Acknowledges Recent Outages, Cites Scaling Challenges and Architectural Weaknesses
https://www.infoq.com/news/2026/04/github-outages-scaling/
[6] HUMAN Security — 2026 State of AI Traffic & Cyberthreat Benchmark Report
https://www.humansecurity.com/learn/resources/2026-state-of-ai-traffic-cyberthreat-benchmarks/
[7] GitHub Blog — Automate repository tasks with GitHub Agentic Workflows
https://github.blog/ai-and-ml/automate-repository-tasks-with-github-agentic-workflows/
[8] InfoQ — GitHub Agentic Workflows Unleash AI-Driven Repository Automation
https://www.infoq.com/news/2026/02/github-agentic-workflows/
[9] The Register — Hashicorp co-founder Mitchell Hashimoto says GitHub ‘no longer a place for serious work’
https://www.theregister.com/2026/04/29/mitchell_hashimoto_ghostty_quitting_github/
[10] The Register — GitHub says sorry and says it will do better as uptime slips
https://www.theregister.com/2026/04/29/github_says_sorry_and_says/
[11] byteiota — GitHub’s Reliability Crisis: 8 Outages in 2 Months
https://byteiota.com/github-reliability-crisis-three-nines/
[12] Jonas Hietala — From GitHub to Codeberg/Forgejo
https://www.jonashietala.se/blog/2026/04/28/from_github_to_codebergforgejo/
Support This Series
If these articles have been helpful, consider buying me a coffee