GitHub stopped publishing aggregate uptime years ago. A developer rebuilt it from scratch — and the numbers behind it explain 2026's AI-traffic infrastructure crisis.
A few weeks ago we covered how to read Claude's status page to understand the real health of an AI service. Today's the counterpart: GitHub, the platform almost the entire software development ecosystem runs on — which stopped publishing aggregate uptime numbers years ago.
That's why The Missing GitHub Status Page exists, a project by Marek Šuppa that reconstructs GitHub's availability history from the public status Atom feed, comparing archived snapshots going back to 2017. GitHub still posts individual incidents, but the aggregate uptime summary vanished from its official page — which is exactly the gap this independent mirror fills.
Why this matters right now
The numbers behind that "missing page" tell a very concrete story: GitHub is being hit by a volume of traffic it wasn't built to absorb, and the cause is a single factor — AI agents writing, committing, and opening pull requests at machine pace, not human pace.
According to figures confirmed by GitHub's own COO, Kyle Daigle, the platform processed roughly 1 billion commits across all of 2025. By 2026, the pace reached 275 million commits per week. Do the math: in a little under four weeks, GitHub now receives the same volume of activity it received across the full twelve months of 2025.
That jump isn't gradual — it's a wall. And it shows:
- AI-agent-opened pull requests went from ~4 million in September 2025 to ~17 million in March 2026.
- GitHub Actions compute went from 500 million minutes/week in 2023, to 1 billion in 2025, to 2.1 billion minutes in a single week in early 2026.
- Claude Code alone went from ~100,000 weekly commits in late September 2025 to 2.6 million per week — a 25x jump in three months.
The result: cascading incidents
GitHub reported nine availability incidents in May 2026 alone, with third-party measurements putting real uptime below the "three nines" standard the industry takes for granted. Microsoft's response was to shift GitHub traffic onto Azure — and when that wasn't enough, to start leaning on AWS infrastructure too, its direct cloud competitor, just to keep the load up.
The root cause GitHub's own CTO acknowledged: fast load growth, tightly coupled services that propagate local failures, and a lack of protection against anomalous client traffic. In other words: the infrastructure was sized for human-paced development, and autonomous agents operate on a genuinely different pattern — not just faster, but different in kind.
The takeaway for any technical team
If your product or stack depends on GitHub (and almost everyone's does), this isn't an unrelated infrastructure curiosity — it's a signal of where load across the whole ecosystem is headed. Worth doing:
- Monitor your own CI/CD pipelines for sensitivity to third-party saturation spikes.
- Stop assuming "three nines" SLAs as a guarantee when the provider itself admits it isn't meeting them.
- Design for graceful degradation so your system keeps working (even partially) when GitHub, npm, or any external dependency has a bad week.
Next time you see a "boring" all-green status page, remember there's an infrastructure arms race against AI traffic behind that green — and sometimes, as with GitHub, the full picture isn't even published. Someone had to rebuild it.
Want us to review how resilient your stack is to these dependencies? Reach us on WhatsApp →
Conversation