The Pulse: AI load breaks GitHub – why not other vendors?
The Pragmatic Engineer · email · 2026-05-07 source ↗ Reader 🖥️
GitHub's ongoing reliability crisis is not adequately explained by AI-driven load increases alone; it reflects deeper organizational and technical failures that competitors have avoided, making GitHub increasingly unfit for professional software development.
practical · argumentative — The article argues that GitHub's reliability crisis is partly self-inflicted due to poor planning, not solely caused by AI load, and implicitly argues professionals should consider alternatives. It uses evidence (outage data, quotes, competitor comparisons) to build a case.
Structure
| Part | Role |
|---|---|
| Data integrity incident (squash merge bug) | Evidence — establishes that GitHub's problems go beyond availability to data integrity, the most serious class of failure |
| Ongoing outages catalog (Elasticsearch, PRs disappearing, Actions failures, security vulnerability) | Evidence — demonstrates the breadth and frequency of failures across multiple subsystems |
| Mitchell Hashimoto quits GitHub | Narrative evidence — a high-profile, credible user validates the severity through action, not just complaint |
| CTO blames AI agent load (3.5x increase) | Presents GitHub's official explanation, then immediately undermines it with counter-evidence |
| Comparison with other vendors and Google's 10x preparation | Counter-argument — if the load increase were truly the cause, competitors would be failing too; they are not |
| Tech debt, organizational debt, Azure migration | Alternative explanation — the real causes are structural, not external |
| GitHub alternatives section | Practical conclusion — the implicit 'you should do X' of this practical text |
Key terms
- zero nines
Reliability below 90% uptime — a deliberate inversion of the industry standard 'number of nines' metric (99.9%, 99.99%) to emphasize how far GitHub has fallen - data integrity incident
A failure where GitHub's merge queue silently produced incorrect merge commits, losing code — distinguished from mere availability outages as a categorically worse class of failure - innovator's dilemma
GitHub's pre-AI workflows and capacity planning, which made it successful, now prevent it from adapting to the AI-agent-driven usage pattern shift - organizational debt Organizational Debt
The coordination overhead of 4,000 employees (1,000 engineers) with cross-team dependencies that slow response to crises - self-hosted forge Open-Source Platform Exodus (Leaving GitHub)
Open-source, locally hosted alternatives to GitHub (e.g., Forgejo) that give teams full control over availability
Propositions
- explicitA 3.5x load increase over two years is not an adequate explanation for GitHub's reliability failures at their scale and resources.conf: high
- explicitData integrity failures are categorically worse than availability outages and GitHub's leadership downplayed the severity of the merge queue bug.conf: high
- explicitOther infrastructure vendors (Vercel, Linear, Sentry, Railway, GitLab, Bitbucket) are handling comparable AI-driven load increases without similar reliability crises.conf: high
- explicitcontestedGitHub's problems are substantially self-inflicted, stemming from tech debt, organizational debt, and a simultaneous datacenter-to-Azure migration.conf: highcontradicts ←Andrew Kelley Interview: Why He Built Zig, Banned AI Contributions, and Moved Zig off GitHub · p5 — Kelley attributes Zig's GitHub CI failures to rising AI workloads, in tension with that piece's argument that GitHub's reliability problems are 'substantially self-inflicted' (tech debt, org debt, Azure migration) rather than primarily AI-load driven.extends ←Does GitHub still merit "top git platform for AI-native development" status? · p11 — extract-ai-load-breaks-github attributes GitHub's crisis to self-inflicted technical causes (tech debt, org debt, Azure migration); this document adds a specific organizational mechanism behind that debt — no CEO since Dohmke's departure and Microsoft-internal Copilot politics — without which the 'organizational debt' claim stays abstract.
- explicitGitHub failed to anticipate AI-driven load growth despite industry-wide signals that were visible a year earlier (e.g., Google preparing for 10x).conf: high
- implicitGitHub's official status page systematically understates the true frequency and severity of outages experienced by users.conf: high
- implicitMicrosoft's ownership of GitHub, rather than providing resource advantages, may have contributed to the organizational overhead that slowed response.conf: high
- implicitcorroboratedThe AI agent wave will create market openings for new entrants in code hosting that are architectured for 30x+ scale from the start.conf: mediumsupports ←Does GitHub still merit "top git platform for AI-native development" status? · p6 — Pierre Computer/Code.storage is a concrete, named instance of the market opening for new, AI-scale-architected code-hosting entrants that extract-ai-load-breaks-github predicted GitHub's crisis would create.
- implicitConcurrent infrastructure migration (datacenter to Azure) during a load spike is a compounding risk factor that turns manageable problems into visible outages.conf: high
Arguments
GitHub's reliability crisis is not primarily caused by AI load but by organizational and technical failures. strength: high
Explicit premises:
- GitHub's load increased 3.5x over two years — a manageable increase for a well-resourced organization
- Competitors handling similar load spikes are not experiencing comparable reliability problems
- Google prepared for 10x load increases a year before GitHub even began planning for it
- GitHub has 18 years of tech debt and 4,000 employees creating organizational overhead
Implicit premises:
- A well-run engineering organization backed by the world's largest tech company should be able to handle a 3.5x load increase over two years
- The comparison with competitors is valid despite differences in scale and architectural complexity
- The ability to forecast and plan for load changes is a basic competency expected of infrastructure companies
Inferences:
- Microsoft's management of GitHub may be a root cause — the organizational bloat and slow planning are symptoms of large-company dysfunction
- GitHub's monopoly position in developer tools reduced its incentive to invest in resilience pre-crisis
GitHub is no longer suitable for professional software development work. strength: high
Explicit premises:
- GitHub has been experiencing daily outages lasting 2-3 hours on average for 90 days
- A data integrity bug silently corrupted merge results for 2,092 pull requests
- GitHub's leadership downplayed the severity rather than issuing sincere apologies
- Reliability is at 'zero nines' (85.51% uptime)
Implicit premises:
- Professional software development requires tools with at least 99.9% availability
- A platform that can silently corrupt your code cannot be trusted regardless of availability metrics
- A vendor that downplays data integrity incidents cannot be trusted to prioritize fixing them
Inferences:
- The reputational damage may be irreversible for some users even if GitHub eventually fixes reliability
GitHub's CTO explanation (AI load) is partially a deflection from organizational accountability. strength: medium
Explicit premises:
- The CTO's chart had no Y-axis, obscuring the actual magnitude
- GitHub only started capacity planning for major growth in October 2025, months after the industry recognized the trend
- The actual load increase was 3.5x, not the dramatic spike the chart visually implied
Implicit premises:
- Publishing a chart without a Y-axis is a deliberate choice to create a more alarming visual impression
- Blaming external forces (AI agents) is more palatable than admitting planning failures
- Engineering leadership is accountable for forecasting, not just reacting
Narratives
- Mitchell Hashimoto, founder of HashiCorp and creator of Ghostty, kept a daily journal marking days with GitHub outages; almost every day got an X. After 18 years on GitHub, he announced he was leaving.
→ Provides a high-credibility, emotionally resonant case for the proposition that GitHub is unfit for professional work. Hashimoto's stature in the developer community makes his departure a signal, not just a complaint. - Can Duruk at Modal discovered GitHub had silently corrupted their repository's merge history and had to manually recover lost commits; GitHub's COO used inflated denominators to minimize the impact.
→ Supports the proposition that GitHub's leadership is downplaying severity. The contrast between the user's emergency (digging into git history to recover code) and the executive's PR framing ('huge denominator') is the argument. - Google's SRE teams had been preparing for 10x code volume increase a year before GitHub even started planning for 10x capacity.
→ Supports the proposition that GitHub's failure to forecast was avoidable — the signals were industry-wide.
Questions addressed
- ✅ Why has GitHub's reliability been so poor recently?
GitHub CTO attributes it to a 3.5x load increase from AI agents, but the author argues the real causes are tech/organizational debt, a simultaneous Azure migration, and failure to plan ahead. - ⭕ Why aren't other vendors suffering the same AI-load-driven outages?
The author notes that competitors are handling it but does not deeply analyze why — he gestures at GitHub's unique tech debt and organizational size but does not compare architectures. - ✅ What should developers do about GitHub's reliability problems?
Consider alternatives: GitLab, Bitbucket, self-hosted forges like Forgejo, or wait for new startups. - ⭕ Is Microsoft's ownership of GitHub a factor in these failures?
The author implies it strongly but does not make the argument explicitly — noting Microsoft has 'more resources than any competitor' yet failed.
Gaps
- incompleteThe competitor comparison lacks depth. Saying Vercel, Linear, and Sentry handle AI load better ignores that these services have fundamentally different architectural profiles (stateless APIs vs. GitHub's stateful git storage, merge queues, and CI/CD). The comparison needs to account for architectural complexity, not just load volume.
Read next: Architecture deep-dives on how GitLab or Bitbucket handle similar stateful workloads at scale; post-mortems from services that did scale successfully through AI load spikes. - incompleteThe article does not examine whether AI agents' usage patterns (high-frequency, bursty, API-heavy, low-value-per-request) are qualitatively different from human usage in ways that make them harder to scale for — beyond simply 'more load.'
Read next: Analysis of AI agent traffic patterns vs. human developer traffic patterns on infrastructure services; rate limiting and traffic shaping strategies for AI agent workloads. - uninformedThe article assumes competitors are 'presumably experiencing similar load spikes' without data. It is possible that GitHub's dominance means it absorbs a disproportionate share of AI agent traffic, making the comparison unfair.
Read next: Market share data on AI agent tool integrations; which platforms AI coding tools (Cursor, Copilot, Claude Code) actually target most heavily. - incompleteNo discussion of whether GitHub could implement rate limiting, pricing changes, or architectural isolation for AI agent traffic specifically — treating agent and human traffic differently.
Read next: GitHub's own blog posts on agent rate limiting; how cloud providers differentiate pricing for automated vs. interactive workloads.