Microsoft asks its rival for help
In one of the more striking infrastructure admissions of the year, Microsoft confirmed on June 16 that it is routing a portion of GitHub's workloads through Amazon Web Services, the cloud platform of its single largest competitor. The move, first reported by Business Insider, is being framed as an operational stop gap rather than a strategic realignment. Microsoft described it as exploring a broader multicloud strategy to achieve additional scalability and flexibility. Stripped of the corporate phrasing, the situation is simpler. GitHub could not keep up, and Azure could not absorb the demand fast enough, so Microsoft turned to AWS for overflow capacity.
The optics are remarkable for a company that has spent years urging customers to standardize on Azure. That Microsoft would send GitHub traffic to AWS at all, even temporarily, signals how acute the capacity problem has become. AWS is reportedly being used as burst capacity for GitHub Actions runners and Codespaces environments, along with providing redundancy during Azure maintenance windows. This is not Microsoft hedging its cloud loyalties. It is Microsoft triaging an emergency, and the choice to use a rival's infrastructure rather than wait for its own tells you how little slack remained in the system.
The agent surge that broke the model
The root cause is the explosive growth of AI coding agents, and the numbers are staggering. Pull requests opened by AI agents on GitHub jumped from roughly 4 million in September 2025 to more than 17 million by March 2026, an increase of around 325 percent in six months. GitHub Actions weekly compute grew from about 500 million minutes in 2023 to 2.1 billion minutes in a single week in early 2026. The platform is now processing around 275 million commits per week and is on pace for roughly 14 billion commits in 2026, up from about 1 billion in all of 2025.
These are not the usage curves infrastructure planners build for. They reflect a fundamental change in who, or what, is using the platform. When humans write code, the rate of pull requests and commits is bounded by the number of developers and the hours in their day. When autonomous agents write code, that ceiling disappears. A single developer orchestrating multiple agents can generate the activity of a small team, and the agents run continuously. GitHub was architected for a world of human developers, and that world ended faster than its capacity plans assumed.
Enterprise SLAs took the hit
The consequences landed where they hurt most, on reliability commitments that enterprise customers pay for and plan around. GitHub logged nine service degrading incidents in May 2026, and availability fell to roughly 88.4 percent in June. For context, the enterprise standard is three nines, or 99.9 percent availability, which allows for less than nine hours of downtime per year. An availability figure in the high 80s is not a minor degradation. It represents the kind of unreliability that disrupts continuous integration pipelines, blocks deployments, and forces engineering teams to build contingency plans around a tool they once took for granted.
This is the part that should concern technology executives most. GitHub is not a peripheral service. For a vast number of organizations it is the backbone of software delivery, the system through which code is reviewed, built, and shipped. When it falls below enterprise reliability thresholds, the disruption cascades through every team that depends on it. The AWS arrangement is, in effect, Microsoft buying reliability from a competitor because its own platform could not deliver it on the timeline customers require. The stop gap exists precisely because the SLA breaches were real and customer facing.
Migration could not keep pace
Compounding the problem is a migration already in motion. Microsoft has been moving GitHub onto Azure, with a target of completing the transition by 2027. By early 2026, internal infrastructure targets had been revised dramatically, from a planned 10 times capacity increase to roughly 30 times, as agentic development usage blew past forecasts. The migration cannot proceed fast enough to absorb the agent driven surge while GitHub is simultaneously undergoing a fundamental architectural redesign. The platform is being rebuilt and overwhelmed at the same time, which is the worst possible combination.
This is a cautionary tale about capacity planning in the age of AI. Microsoft is among the most sophisticated infrastructure operators in the world, with effectively unlimited resources and deep expertise. If its forecasts for GitHub were off by a factor of three in a matter of months, the implication for everyone else is sobering. The traditional approach of projecting demand from historical growth rates simply does not work when the nature of the workload changes underneath you. Agentic AI does not grow demand linearly. It introduces a step change, and infrastructure built for the old curve cannot bend fast enough to meet it.
What this means for technology leaders
The GitHub episode is a preview of a problem many organizations will face as agentic AI moves from experiment to production. Any system that agents interact with at scale, whether a code repository, an API, a database, or an internal tool, will see usage patterns that bear no resemblance to human driven baselines. Capacity that seemed generous for human users can be exhausted in weeks once agents are unleashed against it. Technology leaders should be stress testing their assumptions now, asking not how much their teams use a system today but how much a fleet of agents could use it tomorrow.
There is also a strategic lesson in Microsoft's willingness to use AWS. Multicloud, long debated as a matter of preference and negotiating leverage, is becoming a matter of resilience. When demand spikes unpredictably, the ability to burst into a second provider's capacity can be the difference between maintaining service and breaching commitments. Even a company with Microsoft's resources found value in that flexibility under pressure. For enterprises with far less capacity to spare, the case for architecting workloads that can move between clouds, however unfashionable that has been, just got stronger.
A signal worth heeding
It would be easy to read this as a story about Microsoft's embarrassment, but that misses the point. The more important signal is what it reveals about the trajectory of software development itself. Agents are now generating a meaningful and rapidly growing share of all activity on the world's largest code platform, enough to overwhelm infrastructure built by one of the most capable operators in the industry. That is not a temporary anomaly to be engineered away. It is the new baseline, and it is still climbing.
GitHub will adapt, Microsoft will expand Azure capacity, and the AWS arrangement will eventually wind down. But the underlying dynamic is permanent. The systems that support software development were designed around human limits, and those limits no longer apply. Every organization building or operating developer infrastructure should treat this as a warning shot. The question is no longer whether agentic AI will reshape the load on your systems, but whether your systems can survive the reshaping. Microsoft, caught flat footed despite every advantage, just demonstrated how easy it is to underestimate.
