GitHub is not shrinking. It still gains a new user roughly every second, hosts over 600 million repositories, and saw nearly a billion commits in 2025. But popularity and reliability are not the same thing, and a handful of prominent departures — Ghostty, the Zig programming language, the audio editor Tenacity, and smaller projects like Dillo and Hare — are forcing a question that has little to do with which company owns the platform: how much trust can one central service absorb before serious teams start treating it as a risk rather than a convenience?
Downtime as the tipping point
The maintainers who’ve left don’t describe a single catastrophic failure. They describe erosion. Independent monitoring by IncidentHub logged 257 incidents on GitHub between May 2025 and April 2026, 48 of them classified as major outages, adding up to more than 112 hours of significant downtime — roughly one serious disruption a week for a year. GitHub Actions, the automation service many teams depend on to test and ship code, was the single most affected component, with 57 outages of its own.
Hashimoto’s own account is almost mundane by comparison, which is what makes it persuasive: he kept a private journal marking an "X" on every day an outage blocked his work, and wrote that "almost every day has an X". That’s not a dramatic headline event — it’s the slow discovery that a tool you’d stopped questioning had quietly become unreliable in a way you couldn’t route around.
Crucially, Hashimoto was careful to separate two things that get conflated in this debate: Git, the underlying version-control technology, and GitHub, the company’s hosting and collaboration service built on top of it. "The issue isn’t Git, it’s the infrastructure we rely on around it: issues, PRs, Actions, etc.," he noted. Git is distributed by design — any copy of a repository already contains its full history, which is why moving the code itself is technically trivial. What’s hard to move is everything GitHub bundled around that code: the issue tracker, the pull-request review history, the automation pipelines, and the accumulated trust that lets a stranger verify a project is legitimate just by looking at its GitHub page.
Why the load changed faster than the architecture
GitHub’s own engineering leadership has offered an explanation for why outages accelerated when they did. CTO Vlad Fedorov said the company began a plan in October 2025 to increase capacity tenfold, aiming to improve reliability — only to conclude by February 2026 that it actually needed to design for thirty times the previous scale, driven by a sharp acceleration in AI-agent-driven development workflows. Complementary reporting frames the scale of that shift starkly: AI-generated pull requests reportedly rose from around 4 million to 17 million in six months, a jump of roughly 325%. Those figures come from a single secondary account rather than GitHub’s own disclosures, so they’re worth treating as an order-of-magnitude signal rather than an audited statistic — but the direction matches what GitHub’s CTO himself described.
The underlying mechanic is worth understanding, because it explains why an outage in one corner of the service can cascade everywhere else.
flowchart TD A[Pull request opened] --> B[Git storage & mergeability check] A --> C[CI / Actions pipeline] A --> D[Search & notifications] A --> E[Permissions & webhooks] C --> F[Shared databases and job queues] D --> F E --> F
A human developer opening one pull request triggers this chain once, at a pace the system was built around. An automated agent working through dozens of parallel branches can trigger the same chain hundreds of times in minutes. When several of those subsystems share the same underlying databases and queues, a slowdown in one — say, a search index or a token-verification cluster — has room to ripple into services that have nothing obviously to do with it. That’s a familiar pattern in large distributed systems generally, not something unique to GitHub, but it explains why "just add more servers" doesn’t fully solve the problem: the coupling between services matters as much as raw capacity.
It’s worth stressing what this evidence does not establish. It doesn’t prove AI traffic is the sole cause of every outage — IncidentHub’s own breakdown attributes incidents to a mix of capacity limits, configuration mistakes, third-party dependency failures, and plain infrastructure problems like a fiber cut. AI-driven load appears to be a major stressor layered on top of an already complex system, not a single smoking gun.
Not one complaint, several
Political and technical objections get lumped together in headlines, but they’re distinct arguments with different implications for maintainers.
| Reason cited | What it actually means for a project |
|---|---|
| Repeated outages and slow reviews | Work gets blocked unpredictably; CI and pull-request queues stall for hours |
| Governance and ownership concerns | Some maintainers distrust decisions made by a large corporate parent, separate from uptime |
| AI-era product direction | Frustration that the platform now optimizes for AI features rather than core maintainer workflows |
| Concentration risk | Relying on one host for code, discussion, and CI means one outage stalls everything at once |
| Archival and discoverability value | GitHub accidentally became the place projects are found and trusted — that’s the hardest part to replace |
The alternatives aren’t a free lunch
Codeberg, Sourcehut, self-hosted Forgejo or Gitea instances, and GitLab’s self-managed option are all real, functioning choices, and some — like the Dutch government’s own Forgejo-based platform — show institutional appetite for sovereignty over convenience. But moving code is the easy part; rebuilding the social layer around it — a project’s issue history, its reputation, the casual discoverability that lets a stranger trust a maintainer — takes far longer, if it happens at all. Independent security review of Forgejo, the software underpinning Codeberg, has also turned up meaningful vulnerabilities, a reminder that smaller, younger platforms carry their own operational risk rather than simply inheriting GitHub’s polish without its problems.
The real lesson
None of this means GitHub has become unusable, or that a mass exodus is already underway — the departures so far are prominent but few. What they reveal is more structural: when a single platform becomes the collaboration layer, the CI system, and the infrastructure backbone for millions of projects at once, its failures stop being minor inconveniences and start being strategic risks. The question worth asking isn’t simply "GitHub or something else" — it’s how much dependency any team is willing to concentrate in one place, and what they’d lose the day that place stops being dependable.
