WHAT MICROSOFT CONFIRMED — AND WHAT IT POINTEDLY DID NOT
The shape of Microsoft's June 16 statement is worth reading closely, because it is constructed to confirm exactly one fact and withhold exactly one other. The company acknowledged, in its own words, that GitHub is drawing on multiple cloud providers to absorb capacity it could not otherwise handle, and it framed that admission around a demand spike rather than a failure of its own infrastructure planning. What it declined to do — twice, according to reporters who put the question directly — was confirm that the second provider is AWS. That distinction matters less for what it hides than for what it reveals: Microsoft is comfortable being seen as a company whose own product outgrew its own cloud, but considerably less comfortable being seen turning to Amazon, the company against which Azure has spent a decade positioning itself as the credible alternative. Amazon's silence is the easier read; "we don't comment on individual customers" is boilerplate the company applies uniformly, confirming nothing about scale or terms.
The unconfirmed half of the story still rests on two anonymous sources reported by Business Insider, and that detail belongs in any honest account of what is known. But the parts that don't require anonymous sourcing — GitHub's own incident history, Microsoft's own acknowledgment of multi-cloud capacity help, and a GitHub COO's own public commit-volume disclosure — are sufficient on their own to establish that this is a real capacity crisis, regardless of which company's hardware is absorbing the overflow.
THE TRAFFIC THAT BROKE THE PLAN
GitHub COO Kyle Daigle disclosed in April that the platform was processing roughly 275 million commits a week, putting it on pace for around 14 billion commits in 2026 — up from roughly 1 billion for all of 2025. That is not a gradual climb; it is a step change of more than an order of magnitude in a single year, and commits are the slow-moving end of the traffic. The faster-moving end is what autonomous coding agents generate on top of human activity: AI-opened pull requests rose from about 4 million in September 2025 to 17 million by March 2026, and GitHub Actions compute minutes — the CI/CD jobs that fire every time a branch is pushed or a pull request is opened — went from 500 million minutes in all of 2023 to 2.1 billion minutes in a single week in early 2026.
The structural problem behind those numbers is not just their size but their shape. GitHub's capacity planning, like every platform built for a human user base, assumes daytime peaks, weekday concentration, and weekends with materially lighter load — the rhythm that lets an operator provision for an average and absorb the occasional spike. Autonomous agents do not work that way. They operate continuously through the API and command line, opening pull requests, triggering builds, and pushing commits at whatever rate their orchestration logic allows, with no concept of after-hours or holidays. A platform sized for human cadence is, by construction, undersized for a population of users that never sleeps — and GitHub crossed that threshold sometime in the last two quarters.
NINE INCIDENTS IN MAY, AND AN AVAILABILITY NUMBER GITHUB HASN'T PUBLISHED YET
GitHub's own incident record gives the clearest picture of what the traffic surge actually does to a production platform. The company logged nine service-degrading incidents in May 2026, including a database schema migration on a high-traffic table that produced over an hour of elevated latency and pull-request failures on May 4, and a pair of connected Actions outages on May 5 and 6 in which the remediation for the first incident introduced the configuration error that caused the second. Copilot code review was not spared either: roughly 8,500 code review requests timed out during the May 4 window. Reporting since has put GitHub's tracked availability for June at a level — cited at roughly 88.4 percent — that would represent a sharp departure from the 99-percent-plus thresholds enterprise customers typically expect to be built into a platform-level SLA, though GitHub has not yet published an official June availability report confirming that specific figure.
The pattern across those incidents — a routine maintenance operation destabilizing a high-traffic table, a fix for one Actions outage causing a second — is the signature of infrastructure operating closer to its ceiling than its operators are comfortable with, where the margin for routine operational work to go wrong without cascading has been narrowed by the volume sitting on top of it. That is the condition any team running production infrastructure recognizes as a leading indicator of more outages to come, not fewer, until the underlying capacity constraint is addressed rather than patched around.
WHY AZURE CAN'T ABSORB THIS ALONE — YET
GitHub has been migrating off its original monolith architecture and onto Azure for years, and that migration was, by May 2026, about 40 percent complete on a path toward 50 percent by July. The arithmetic problem is that the migration and the AI-driven traffic surge are moving on different timelines: the architectural work needed to let GitHub's monolith run natively and efficiently on Azure at this scale takes years to finish properly, while the agent-driven load it needs to absorb arrived in months. Reporting on the AWS arrangement describes it as targeted rather than wholesale — aimed specifically at burst compute and storage workloads tied to GitHub Actions runners and Codespaces environments, the parts of the platform most directly hit by AI-agent CI/CD activity, while code storage, authentication, and core web serving stay on Azure. That scoping is the difference between "Microsoft quietly handed its rival a slice of GitHub" and "Microsoft is renting overflow capacity for a workload category it didn't originally provision for" — a less dramatic story, but a more accurate one, and still a real concession that Azure's own buildout has not kept pace with the product it hosts.
THE $7.6 TRILLION BACKDROP
GitHub's capacity crunch is a single-company story, but it is happening inside an industry-wide one. Goldman Sachs raised its baseline forecast this month to $7.6 trillion in cumulative AI infrastructure capital spending — compute, data centers, and power — between 2026 and 2031, implying roughly $765 billion in 2026 alone, climbing toward $1.6 trillion a year by the end of the forecast window. Silicon accounts for $5.1 trillion of that figure, with Nvidia alone capturing an estimated 75 percent share; power, at $358 billion, is the smallest line item by dollar amount but the one Goldman's analysts flag as the binding constraint on everything else, since next-generation racks running at 500-plus kilowatts are now a liquid-cooling-only proposition that takes years, not quarters, to permit and build. Set against that backdrop, a single platform team scrambling for burst compute from a rival's cloud reads less like a Microsoft-specific stumble and more like the most visible instance yet of a capacity gap that Goldman's own numbers say will keep widening before it narrows — every hyperscaler is racing to build power and data-center capacity for demand curves that the last eighteen months of AI agent adoption have made look conservative in hindsight.
WHAT THIS MEANS FOR TEAMS RUNNING AI CODING AGENTS AT SCALE
For engineering organizations that have wired autonomous coding agents into their CI/CD pipelines — and the number doing so has grown fast enough to be a meaningful share of GitHub's own traffic surge — the practical lesson is that the platforms underneath those agents were not built for the request patterns those agents generate, and the operators of those platforms are currently discovering that in production rather than in capacity planning. That argues for teams to treat agent-driven CI/CD load as a distinct capacity category worth monitoring on its own terms — separately from human-driven build volume — rather than assuming a platform's published SLA was written with continuous, 24-hour, machine-paced traffic in mind. It also argues for rate-limiting and backoff logic in agent orchestration layers that is more conservative than what teams would build for human-triggered pipelines, since an agent with no concept of "it's 2 a.m., maybe don't retry immediately" is precisely the traffic pattern that turned a routine database migration into an hour-long outage on May 4.
The harder strategic question, for GitHub and for every platform now absorbing agent-driven load, is whether multi-cloud overflow arrangements are a stopgap on the way to a properly resized single architecture, or a permanent feature of running infrastructure for a user base that includes both humans and machines operating at fundamentally different rates. Microsoft's own framing — "tested our infrastructure's limits" — suggests the company still sees this as a temporary mismatch to be engineered away. Whether that holds depends on whether AI agent activity on developer platforms plateaus or keeps compounding at the rate it has for the past two quarters; nothing in this week's numbers suggests it is slowing down.