Microsoft confirmed in June that GitHub is routing traffic through AWS. Its own Azure infrastructure cannot absorb what AI coding agents are doing to it. The 99.9% enterprise SLA GitHub sells to companies ran at 88.4% availability last month. For developers whose deployment pipelines, code review workflows, and release processes depend on GitHub, that gap is production downtime in everything but name.
The Copilot outages from earlier this year were operational failures: authentication backends, storage misconfigs, queue exhaustion. Each one was recoverable. GitHub fixed the thing that broke and availability returned. This is different.
The Commit Curve Broke
GitHub COO Kyle Daigle put a number on it in April: 275 million commits per week, on pace for 14 billion in 2026. In 2025, GitHub processed roughly one billion commits total. That's a 14x increase in annual volume in a single year.
The infrastructure team planned for a 10x capacity expansion in October 2025. By February 2026, they'd revised the target to 30x. The capacity planning cycle was already wrong before the expansion finished.
The driver is AI agents. Cursor, Claude Code, Copilot agents, Devin, and the broader category of coding tools access GitHub through the API and command line. They never log in through the UI. They don't take weekends. They don't follow the weekday peaks and overnight troughs that GitHub's capacity models were built around for fifteen years. When a human developer finishes work on Friday evening, the commit curve drops. When an AI agent finishes a task, it starts the next one.
What Constant Load Breaks
GitHub's infrastructure, like most internet platforms, was sized for peak human demand with margin. The usage curve has predictable shape: weekday peaks, overnight drops, weekend lows. Capacity planning builds around that shape because it determines how much infrastructure you need at worst-case conditions. It also means there are off-peak hours when the platform can catch up, run maintenance, shed load.
AI agents removed the off-peak hours.
The platform now runs at something approaching constant load rather than the variable load that let infrastructure recover between peaks. The specific failure mode that five separate incidents on April 1 and 2 exposed — Copilot backend resource exhaustion, code search down for 8.7 hours, Cloud Agent degraded for four hours — wasn't an unusually high traffic spike. It was caused by the baseline having moved up high enough that normal variation pushed specific services past threshold.
GitHub's nine May incidents and 88.4% June availability aren't a bad run of luck. They're what happens when the floor of your usage is where your planning models put the ceiling.
The Maintainer Version of the Same Problem
Open source maintainers are experiencing a version of this at the pull request level.
AI agent PRs hit 17 million in March, up from 4 million in September 2025. Prominent open source maintainer Xavier Portilla Edo reported publicly that one in ten PRs created with AI tools is legitimate. The other nine require his attention — reading the PR, assessing it, closing it with or without explanation — before he can confirm it's noise. That's a 10x increase in review overhead on contributions where 90% of the work product is irrelevant.
GitHub shipped two settings on February 13 to give maintainers a response: disable pull requests entirely, or restrict them to verified collaborators. The informal name for these settings — the "kill switch" — captures what they actually are. A panic button for maintainers who can no longer absorb the volume of automated submissions.
The structural problem is the same at the project level as at the platform level. Norms around PR behavior — reviewers will look at it, contributors have some accountability, most submissions are made in good faith — assumed human contribution rates. AI agents submit at machine scale with no friction, no weekend, and no skin in the game.
The 11.6% Your Productivity Data Is Missing
For developers with production systems on GitHub, 88.4% availability means something specific: roughly one in nine hours of the month, something that depends on GitHub isn't working correctly. CI pipelines stall. Deploy gates don't clear. Code review queues back up. Automation that assumes GitHub's API is responsive times out or fails silently.
Standard productivity tracking doesn't account for this. Coding session time is measured. PR throughput is tracked. Deployment frequency shows up in DORA metrics. But when a developer's CI run sits queued for 45 minutes because GitHub is degraded, that time doesn't register as platform unavailability in any dashboard — it looks like a slow afternoon.
METR noted earlier this year that developers in their controlled studies quietly routed hard tasks to AI-enabled sessions and easier tasks to no-AI sessions, degrading the study without being asked to. The same selection effect applies during platform degradation. Developers don't sit idle when GitHub is slow. They switch to something that isn't blocked. That context switch doesn't record itself as "platform-induced interruption." It shows up as a focus pattern shift or an oddly unproductive day.
The 11.6% of hours with degraded GitHub availability aren't absent from your productivity data. They're present as noise you can't currently separate from signal.
The AWS Call Is a Symptom
Microsoft routing GitHub through AWS is easy to read as embarrassment — the company selling enterprise cloud infrastructure can't run its most strategically important product on Azure. That reading isn't wrong.
But the more important signal is what it says about pace. Infrastructure planning cycles run annually. Cloud migration decisions involve multi-month procurement and architectural work. Microsoft was already expanding GitHub's Azure capacity by 30x. They called AWS anyway. That means 30x wasn't enough, and the timeline for a 30x Azure expansion didn't fit the timeline of a platform that needed it last quarter.
AI agents generate commits at machine scale. The entire infrastructure stack — version control platforms, CI providers, code review tools, package registries — was built for human-scale contribution patterns. The assumption embedded in fifteen years of platform design, that commits happen at human pace, dissolved in under twelve months.
Availability will stabilize as capacity catches up. The more durable consequence is that platform risk is now part of the developer productivity equation in a way it wasn't eighteen months ago. At 88.4% monthly availability, your infrastructure doesn't just affect speed. It affects whether work completes at all.
What Comes After the Expansion
The immediate answer to GitHub's capacity problem is throwing more infrastructure at it, which Microsoft is doing. The 30x expansion plus AWS headroom will likely bring availability back toward the SLA number. That's the operational fix.
What doesn't get fixed by more servers is the planning assumption. If AI agent commit volume is growing at 14x annually and the trajectory holds, this quarter's 30x headroom is next year's constraint. GitHub acknowledged this in April, saying they now treat capacity planning as a continuous process rather than an annual one. That's the correct response but it's also a significant change to how a platform at this scale operates.
The smaller question, for developers who track their own productivity rather than GitHub's uptime, is whether your current measurement approach can tell you when the platform is the variable. Platform degradation and developer behavior changes produce similar-looking data: shorter sessions, more context switching, lower output. Distinguishing them requires correlating session data against platform status history, not just activity patterns. Most tracking tools don't do this. We're building it into xeve because the data without it is telling you something ambiguous at the exact moments you most need it to be clear.
AI agents don't have weekends. The platforms they run on are learning that the hard way.