GitHub Adds 4 Million CPU Cores After Outages, Starts Running Actions Jobs on AWS

GitHub said on October 28, 2026 that it has added 4 million CPU cores, 160 petabytes of high-speed storage and 50 terabits per second of network capacity so far this year, after a run of outages caused by a surge in AI-agent activity. On the same day it began running eligible GitHub Actions jobs on Amazon Web Services as well as Microsoft Azure, a notable step for a Microsoft-owned platform.

The numbers explain the pressure. GitHub recorded 1.4 billion commits in April, 2.9 billion in August and 7.4 billion in September. For the teams who depend on it, the practical question is whether this new capacity, and a planned multi-region Azure setup, will finally make the platform dependable, and what they need to change on their side.

Key facts at a glance

• New capacity in 2026: 4 million CPU cores, 160 PB of high-speed storage and 50 Tb/s of network capacity, according to Jay Parikh, Microsoft's executive vice president of CoreAI.
• Demand: 7.4 billion commits in September, up from 1.4 billion in April; more than 40% of pull requests were started by an agent by September, up from 17% in March, according to GitHub's figures.
• Multi-cloud Actions: standard 2-core and 4-core Linux runners may now run on AWS; Free, Pro and Team accounts move automatically, while Enterprise Cloud customers opt in.
• Migration: GitHub expects to finish moving to a multi-region Azure deployment early in 2027, after missing a September 30 goal.
• Action needed: IP allowlists that trust only Azure or Microsoft ranges can block the new runners.

Context: a year of capacity failures

GitHub's reliability problems have been building for months. On August 17 an outage lasted 7 hours and 47 minutes, disrupting github.com, sign-in, Actions, APIs, pull requests, issues and Copilot. It followed an Actions failure on August 6. Data reconstructed from GitHub's status page shows its 90-day availability falling to about 84% on May 7.

GitHub has been candid about the cause. "Neither outage was caused by a code or configuration change," chief technology officer Vlad Fedorov wrote after the August incident. "Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity."

The August outage began when traffic hit a new peak and a critical component in its Central US data centre failed to scale. Recovery was slowed when errors in some Copilot services triggered a client-side retry loop that added load while engineers were restoring traffic. GitHub has since applied consistent retry limits, retry budgets and variable timeouts across service-to-service calls to prevent similar retry storms.

What GitHub is building

Raw capacity is the first layer. By August, GitHub had added more than 3 million CPU cores and 120 PB of storage. The October update raises that to 4 million cores and 160 PB, alongside the 50 Tb/s of network capacity. GitHub said it had installed as much hardware as available power allowed in its existing data centres while speeding up the move to Azure.

Architecture is the second. "Adding capacity matters, but capacity alone won't get us there," Parikh wrote. GitHub says its new Git architecture follows three principles: simplify the primitives, decouple storage from compute, and minimise coordination between systems. The company has said separating compute and storage should allow about 35 times more throughput.

Regional spread is the third. By October 7, 120 of 160 production services were deployed in Azure's Central US region and 13 of 51 primary MySQL databases had moved. Azure handled 65.4% of read traffic for GitHub's core application, 48.3% of Git read traffic and 80.2% of stream-processing traffic. GitHub expects to complete a multi-region Azure deployment early next year.

Actions jobs can now run on AWS

The most immediate change for developers is in GitHub Actions, its continuous integration and delivery (CI/CD) service. GitHub now schedules eligible jobs across what it calls a broader, multi-cloud compute pool, which it says adds capacity, reduces queue times and improves resilience. Eligible Linux jobs may now run on AWS as well as Azure.

The change covers standard 2-core and 4-core Linux runners and compatible 2-core and 4-core larger runners without specialised configurations. It does not apply to Windows runners or to runners with private networking.

For GitHub Free, Pro and Team customers, eligible runners use multi-cloud compute automatically. GitHub Enterprise Cloud customers can opt in under Enterprise settings, then Actions, then Hosted compute cloud providers, by enabling AWS compute. Existing runner labels and workflow syntax do not change.

Where things still fall short

GitHub's own reports show the work is far from finished. "Significant incidents, a capacity pause, and a missed migration target show that the work is not complete," the company wrote in its September availability report.

That report described a pause in Central US deployments and traffic increases on September 11, because capacity was uneven across availability zones; ramps resumed on September 18. On September 13, a background clean-up job overloaded a shared database for about two hours, and roughly 96% of requests to create issues through the web interface were affected. During a planned database failover, an automated emergency process disconnected Central US database copies and disrupted customers in that region.

There has been progress too. GitHub says moving 24 authentication tables off its oldest shared database removed about one million queries per second from its replicas, and weekly deadlocks fell about 77% from their June peak. Changes to Actions cut measured Redis operations by about 28%.

Sceptics will note that demand keeps outrunning supply. Commits more than doubled between August and September alone, and every commit and pull request triggers tests, linting and other automated checks. Whether 4 million extra cores is enough depends on how fast agent activity grows next.

What it means for you

For engineering teams in the US, UK, Canada and Australia, three changes are worth acting on now.

Update network allowlists. GitHub warns that runners in the expanded pool use additional outbound IP addresses. Policies that allow only Azure or Microsoft-owned ranges, including Microsoft Entra Conditional Access policies, can block connections or authentication. GitHub publishes every Actions runner range in the actions array of its meta API (GET https://api.github.com/meta) and recommends syncing allowlists with that endpoint rather than with cloud-specific ranges.

Check data and compliance rules. If your organisation restricts which cloud providers may process build jobs, Enterprise Cloud lets you decide whether to enable AWS compute. Free, Pro and Team accounts do not get that choice for eligible runners.

Plan for outages anyway. Even with new capacity, GitHub's track record this year argues for resilience on your side: cache dependencies, keep a way to deploy if Actions is down, and avoid making a single GitHub service a hard dependency for production releases.

What happens next

GitHub's stated goals give a timeline to watch. It aimed to unlock all available Central US capacity by the end of October 2026, and it expects to complete the multi-region Azure migration in early 2027. The AWS rollout for Actions is rolling, so jobs will shift gradually.

The bigger test is whether the redesigned Git architecture arrives before the next traffic peak. GitHub's guiding principle, in its own words, remains "availability, then capacity, then features."

Takeaways

1. Sync allowlists now with the Actions ranges in GitHub's meta API before your jobs land on AWS.
2. Decide on AWS compute if you are on Enterprise Cloud and have provider restrictions.
3. Track GitHub's monthly availability reports to judge whether the new capacity is working.
4. Build fallbacks for CI/CD and deployments, since a 7-hour outage is possible again.
5. Expect more load from agents. With over 40% of pull requests agent-started, size your own pipelines for higher volume too.