GitHub has added 4 million CPU cores, 160 petabytes of high-speed storage and 50 terabits per second of network capacity so far in 2026, Jay Parikh, executive vice president of CoreAI at Microsoft (Nasdaq: MSFT), whose teams include GitHub, wrote on October 28 at GitHub’s Universe conference. GitHub is also moving to a multi-region deployment in Microsoft’s Azure cloud and expects to finish early in 2027.
The additions follow a run of outages. GitHub’s monthly availability reports count 52 incidents that degraded its services from January through September. After github.com was disrupted for nearly eight hours on August 17, chief technology officer Vlad Fedorov wrote of that outage and an August 6 failure of GitHub Actions, its service for automated builds, tests and deployments: “Both incidents were capacity failures at their core.”
Parikh wrote that hardware alone would not be enough:
Adding capacity matters, but capacity alone won’t get us there. We’ve also had to change the architecture.Jay Parikh, executive vice president of CoreAI at Microsoft, October 28
What GitHub has added, and where
Hardware. On August 20, Fedorov counted “more than 3 million CPU cores” and 120 petabytes added since GitHub’s reliability commitments earlier in the year. Neither post says how much of the hardware sits in GitHub’s own data centers and how much in Azure; Fedorov wrote that GitHub had “installed as much hardware as available power allowed in our existing data centers.”
Azure. GitHub engineers wrote on October 21 that 99.99999% of its repositories have copies in both its own data centers and Azure, which serves about half of Git traffic.
A new Git design. GitHub is moving repository data into Azure Blob Storage, with separate computers that scale with traffic. In internal benchmarks the design “has delivered up to 35 times higher write throughput,” GitHub said on October 6. GitHub is building it while the service runs, with “no maintenance window.”
Why GitHub says it needs more
GitHub ties the demand to AI coding agents. The October 6 post, updated October 26, said pushes grew 4.9 times in a year, to 3.35 billion a month, and that Actions ran 3.26 billion times in September, more than four times as often as a year before. GitHub’s Octoverse report said more than 40% of pull requests in September started with an agent’s first draft, up from 17% in March.
The outages, in GitHub’s words
Nine incidents from GitHub’s own write-ups this year:
Date (length) | What failed | Cause, per GitHub |
|---|---|---|
Feb 2 (3h 45m) | Actions hosted runners, Codespaces | Security policies wrongly applied to storage at its compute provider |
Feb 9 (2h 43m, two spells) | github.com, API, Actions, Git, Copilot | A cache change and app traffic overloaded an authentication database |
Apr 27 (6h 31m) | Search in issues, pull requests, Actions | Scraping from 600,000+ IP addresses overloaded search load balancers |
Aug 6 (9h 9m) | Actions | A routine deployment exposed a capacity weakness |
Aug 17 (7h 47m) | github.com, APIs, Actions, Copilot | A new traffic peak overwhelmed a data center’s load balancers |
Sep 13 (2h 1m) | About 28 services, including issues and sign-ups | A cleanup job overloaded a shared database |
Oct 5 (4h 1m) | Actions hosted runners | A partial network failure between its data center and cloud services |
Oct 7 (19m, two spells) | Writes to Git, pull requests, Actions, API | A new machine with outdated records sent writes to retired databases |
Oct 21 (4h 30m open) | Pull request updates, webhooks, Actions | Load on event streaming; analysis pending |
Source: GitHub’s reports and status page, linked on each date. Lengths, in brackets, are the impact windows GitHub gave; October 21 is how long the incident stayed open on the status page.
Actions has fared worst lately. On October 29, GitHub’s status page showed it at 99.3% uptime over the past 90 days, the lowest of its services. By the formula GitHub published in April, which counts a partial outage at 30% of its length, that works out to about 15 hours of downtime. Pull requests showed 99.83% and Git operations 99.99%.
GitHub has apologized for the outages, and Fedorov said growth was no excuse:
That growth explains the pressure on our systems, but it does not excuse these outages.Vlad Fedorov, chief technology officer of GitHub, August 20
What GitHub has committed to
August 12: the July availability report set a goal of “bringing every production service online” in Azure’s Central US region that quarter, and said GitHub had a “line of sight to get dotcom production traffic out of our datacenters by the end of CY2026.”
October 14: the September report said GitHub had missed its “aggressive September 30 goal” to deploy every production service there. By October 7, 120 of 160 were deployed in Central US and 13 of 51 primary MySQL databases had moved. The report set “a goal of unlocking all available capacity by the end of October.”
October 28: Parikh said GitHub expects to complete the multi-region migration “early next year.”
Monthly reports since June repeat the order Fedorov set out in April: “availability first, then capacity, then new features.”
What it means for teams on GitHub
GitHub says customers will not have to change how they work while it rebuilds, and since April its status page has shown each service’s uptime. Its guidance from recent incidents:
Re-run failed workflows after an Actions outage. In most cases, GitHub’s August report said, “re-running a failed workflow once the incident was over succeeded.”
Check for runs that never started. Some events during the August 6 outage “cannot be replayed automatically,” GitHub said; customers may need to push a new commit, update the pull request or re-run the workflow.
Switch models when one fails. During an October 28 Copilot outage, GitHub recommended “choosing another model to continue using Copilot.”
GitHub said it will publish a fuller account of the October 7 outages in its next monthly availability report.
