Microsoft confirmed on June 16, 2026, that it is routing GitHub traffic through Amazon Web Services — its biggest cloud rival — after an unprecedented surge in AI coding agent activity pushed the platform past the reliability thresholds its enterprise customers contractually expect.

The disclosure, first reported today by Business Insider, comes as GitHub has logged nine service-degrading incidents in May 2026 alone and is tracking at estimated availability well below 99% for June — a level that amounts to multiple days of downtime extrapolated across a full month and that fails the "three nines" standard GitHub's own CTO acknowledged the platform breached in February and March.

AI Coding Agents Shattered GitHub's Traffic Models

The numbers behind this crisis reveal a demand curve that no capacity planning exercise anticipated. GitHub COO Kyle Daigle confirmed in April that the platform was processing 275 million commits per week — putting 2026 on pace for 14 billion total, a 14× increase from the 1 billion commits recorded across all of 2025. GitHub Actions compute minutes tell the same story: weekly usage climbed from 500 million minutes in 2023 to 1 billion in 2025, then hit 2.1 billion in a single week in early 2026.

Pull requests opened by AI coding agents surged from roughly 4 million in September 2025 to more than 17 million in March 2026 — a 325% increase in six months. The agents driving that growth — Cursor, Claude Code, GitHub Copilot, Devin, and dozens of competitors — interact with GitHub in a fundamentally different way than human developers do. They operate continuously via the API and command line, never logging in through the UI, never resting on weekends, and never following the usage curves that GitHub's capacity planning models were built around. Every PR they open triggers a cascade of infrastructure work: database writes, webhook fan-outs to downstream services, runner allocation for CI jobs, search index updates, and artifact storage operations.

When millions of agents do this simultaneously, the cumulative effect resembles sustained load against the platform's own internal services. GitHub CTO Vlad Fedorov acknowledged in an April blog post that GitHub began executing a plan in October 2025 to increase capacity tenfold. By February 2026, that target had been revised to 30× — because agentic development tool usage had grown faster than the infrastructure team's models predicted.

Why GitHub's Architecture Is the Real Problem

More compute alone does not solve this. Fedorov identified the root cause with precision: "rapid load growth, architectural coupling that allowed localized issues to cascade across critical services, and inability of the system to adequately shed load from misbehaving clients."

That language describes a structural problem. GitHub's platform was built in 2008 on Ruby on Rails and still runs a near-two-million-line monolithic application at its core. In a tightly coupled monolith, a failure in one service — an authentication database overloaded by a cache rewrite storm on February 9, for example — cascades immediately to every other service that shares that architectural backbone: GitHub Actions stops running, pull requests become unavailable, Copilot goes dark, and the web interface fails, all simultaneously. The February 9 incident did exactly this, taking down the web UI, pull requests, and Copilot at the same time for multiple hours.

Reaching the 30× capacity target is not a matter of provisioning more servers in the same architecture. It requires a redesign of how the platform queues work, sheds load from overactive clients, and isolates service failures before they cascade. GitHub's CTO has publicly committed to migrating performance-sensitive code from Ruby to Go, reducing single points of failure, and pursuing a multi-cloud approach as structural components of that redesign. That work is underway — but it cannot be finished in the months it takes to stand up more cloud capacity.

This is the gap AWS fills: it buys time. Azure cannot absorb GitHub's traffic fast enough on its current migration timeline, so Microsoft is routing overflow through a competitor's infrastructure while the underlying architectural work continues. As of the May 2026 availability report, 40% of monolith traffic was being served from Azure — up from 8% in February — with Git traffic at 30% and repository replication at 99%.

Microsoft Confirms the Rival Cloud Arrangement

A Microsoft spokesperson confirmed that GitHub is using multiple cloud providers, attributing the arrangement to "the incredible spike in agentic development that began late last year" that has "tested our infrastructure's limits." Microsoft said it is "both accelerating our move to Azure and continuing to explore a multi-cloud strategy to ensure we have the future capacity, compute elasticity and horizontal scale required to support continued growth."

Amazon declined to comment on individual customers.

The competitive context matters. Microsoft and Amazon compete directly for enterprise cloud contracts worth hundreds of billions of dollars annually. Routing a flagship developer platform through AWS rather than Azure sends a signal — acknowledged or not — that Microsoft's own cloud infrastructure cannot currently absorb the demands of its own most strategically important product.

The optics are made more complicated by timing. On June 12, 2026, a securities class-action lawsuit was filed in the U.S. District Court for the Western District of Washington, led by the City of St. Clair Shores Police and Fire Retirement System and targeting CEO Satya Nadella and CFO Amy Hood among others. The suit alleges Microsoft misled investors about Azure capacity constraints and Copilot adoption rates during the period from May 1, 2025, to January 28, 2026. The GitHub capacity situation is directly connected to the Azure constraints at the center of those allegations.

What Enterprise Engineering Teams Should Do Now

For the more than 100 million developers and the enterprises that depend on GitHub Actions for production CI/CD pipelines, the AWS arrangement offers some reassurance — Microsoft is clearly treating this as a priority — but it does not resolve the immediate reliability problem.

Platform availability for June remains below what enterprise customers expect based on outage tracking through mid-month. GitHub has not published an official June availability report as of this writing. The April 9–13 incident period saw agent session wait times peak at 54 minutes against a normal range of 15 to 40 seconds. February and March both failed the three-nines commitment to enterprise customers by Fedorov's own accounting.

Engineering teams running production workflows on GitHub Actions should evaluate their exposure. The specific actions that mitigate risk: establish CI/CD fallback paths to GitLab CI, CircleCI, or self-hosted runners so that a GitHub outage does not halt all deployment pipelines; monitor GitHub's status page proactively and subscribe to incident notifications; engage GitHub enterprise account teams to understand what compensation or remediation commitments apply when availability falls below contracted levels; and consider whether agentic AI workflows — which multiply GitHub API calls by orders of magnitude — should be rate-limited internally before they contribute to platform-wide saturation.

GitHub Is Not Alone in the AI Capacity Crunch

The GitHub situation is not an isolated operational failure — it is the earliest and most visible instance of a structural challenge that every platform running as infrastructure for agentic AI workflows will eventually face. The same week Microsoft's AWS arrangement became public, a previously disclosed deal showed Google paying SpaceX $920 million per month for AI compute capacity from October 2026 through June 2029. Google — which builds and operates its own hyperscale cloud infrastructure — described the arrangement as "bridge capacity to meet surging customer demand" for its Gemini Enterprise AI platform that was "even higher than we expected."

The common thread is that AI agent demand has outrun planning cycles at organizations that were, by conventional measures, among the best-prepared in the world. The lesson for any platform that hosts developer tooling or AI agent workflows is not that these companies miscalculated badly. It is that agentic AI traffic exhibits statistical properties — continuous, correlated, machine-speed, never-sleeping — that existing capacity models have no reliable way to forecast.

The Re-Architecture Imperative

GitHub COO Daigle expressed confidence in early June that the platform would show "fewer and fewer moments where we have an availability problem" by September 2026. That deadline is 14 weeks away.

What must happen in those 14 weeks is not just more compute. The monolithic architecture that allowed February's authentication database failure to cascade simultaneously into Actions outages, Copilot failures, and web UI degradation needs targeted isolation work. The load-shedding mechanisms that Fedorov identified as missing — the ability to deprioritize or disconnect misbehaving clients before they saturate shared infrastructure — need to be implemented and tested at scale. The migration of performance-critical paths from Ruby to Go, which the CTO identified as a parallel architectural track, must continue against a platform that cannot pause for maintenance.

More Azure capacity and temporary AWS overflow buys time. It does not, by itself, rebuild a platform architecture designed for human-paced commits into one capable of serving as the backbone of machine-speed agentic software development. That is the engineering work GitHub must complete — and the timeline is aggressive.

Frequently Asked Questions

Why is Microsoft using AWS instead of its own Azure cloud for GitHub?

Azure is where Microsoft is migrating GitHub, and that migration is ongoing — by May 2026, 40% of monolith traffic had moved to Azure, with a target of 50% by July. The AWS arrangement is a stopgap: the migration cannot happen fast enough to absorb AI-agent-driven traffic surges while the platform simultaneously undergoes a fundamental architectural redesign. AWS capacity provides overflow room while the Azure migration and deeper structural work continue in parallel.

What are AI coding agents doing to GitHub that human developers did not?

AI coding agents operate continuously via the API and command line — they don't follow human usage patterns (daytime peaks, weekends off). They open pull requests, run CI pipelines, and push commits at machine speed, 24 hours a day. Each PR triggers a cascade of infrastructure work: database writes, webhook fan-outs, runner allocation, search index updates, and artifact storage. At 17 million AI agent PRs in a single month, that cascade becomes an enormous sustained load against services that were sized for human-scale traffic.

Is GitHub reliable enough for enterprise CI/CD pipelines right now?

GitHub's own CTO acknowledged the platform failed its "three nines" (99.9% uptime) commitment to enterprise customers in February and March 2026. The platform logged nine incidents in May and outage tracking data indicates availability well below 99% for June as of mid-month. Engineering teams running production pipelines should have fallback CI/CD paths established and should monitor GitHub's status page actively. Microsoft has committed to significant infrastructure investment and COO Kyle Daigle expects improvement by September 2026, but that improvement is not yet confirmed in the availability numbers.

Will adding more cloud capacity from AWS fix GitHub's reliability problems?

Only partially. The deeper issue is architectural. GitHub's platform, built on a Ruby on Rails monolith, has tightly coupled services that allow a single failure — like an authentication database overload — to cascade simultaneously into Actions outages, Copilot failures, and web UI degradation. More compute buys time but does not eliminate the coupling. GitHub's CTO has publicly identified load-shedding capability, architectural decoupling, and migration of performance-critical code from Ruby to Go as necessary structural fixes — and has described the 30× redesign target as a complete architectural rethink, not just a capacity expansion.