GitHub Outage on October 7 Caps a Week of Actions and Git Failures

A bad week, then a worse Wednesday

On October 7, GitHub failed across most of the services developers use every day. It was also the latest in a run of incidents that began at the start of the month. Outage reports on Downdetector began around 10:50 a.m. Eastern time and passed 2,500. GitHub confirmed that webhooks, Actions, pull requests and issues were all degraded.3 Users posting to one outage tracker described the same problems in plain terms: Actions was down, Git operations were down, and pull requests could not be merged. Those reports came from Canada, the United Kingdom and South Africa.2

GitHub's status page gives the most exact timeline. GitHub says it saw widespread impact across its services between 15:06 and 15:16 UTC. It declared that first incident resolved at 16:25 UTC and said it had found the root cause and was applying fixes.1 Less than an hour later the problem came back. Between 16:52 and 17:01 UTC, Actions, Git operations, issues and pull requests failed again, and GitHub called it "a reoccurrence" of the earlier incident. The second incident was closed at 18:04 UTC with a promise of a detailed root cause analysis.1 By 1:03 p.m. Eastern, the status site showed every system working again.3

October 7 did not come out of nowhere. Two days earlier, starting at 18:48 UTC on October 5, GitHub Actions and its hosted runners slowed down. During the worst 90 minutes, 47% of workflow runs on GitHub-hosted runners failed and almost 72% of hosted jobs did not start within five minutes.1 In Germany, where the outage began around 9 p.m. local time, it was reported as a multi-hour shutdown of the CI/CD system that also hit GitHub Pages and billing pages. Developers were told to check overnight build logs and restart jobs by hand.11 On October 6, issues, pull requests and webhooks were briefly degraded, and GitHub paused enterprise migrations for several hours.1 On October 1, Actions jobs were delayed.1

Reports differ on how long it lasted

The accounts disagree about duration, and the difference matters. One widely shared analysis said the October 7 outage ran more than two hours, with full service back about two hours after it started.12 The status page shows something different: two short periods of widespread failure, each about ten minutes, inside longer incident windows.1 Third-party trackers that read the same feed put the two incidents at about 70 minutes and about 47 to 48 minutes.59 StatusGator, which measures its own way, logged much shorter periods of hard downtime.2

The most likely reading is that both versions are true but measure different things. Most of the platform was fully down only briefly. The disruption developers felt lasted much longer, because Actions queues had to drain, webhooks had to catch up and teams could not easily tell whether a failure was theirs or GitHub's. One engineer described a billing hotfix that was approved and waiting to merge but stuck in "queued" for hours. The team spent that time checking its own permissions and billing before anyone opened GitHub's status page.18 That account notes that almost every pipeline the team had, from tests to the deploy trigger, ran only on GitHub-hosted runners. When runners stopped being handed out, the team could ship nothing.18

Automated uptime monitors miss this kind of damage. UptimeRobot said its probes of GitHub's API and raw-content endpoints stayed green throughout the October 5 incident, because the fault was in the Actions job scheduler and runner assignment, which those probes never touch.7 Another monitor reported 100% 30-day API uptime for a stretch that other trackers filled with incidents.19 A green checkmark on a single endpoint says little about whether a team can ship code.

The causes GitHub has disclosed

GitHub had not published a root cause for October 7 when service came back.12 It has explained the incidents just before it, and those explanations show a platform under strain in several places. GitHub said the October 5 Actions outage came from a partial network failure. That failure cut the link between one of its on-premises datacenter regions and some cloud-hosted regional database and storage services. Engineers fixed it by moving traffic to healthy regions and adding compute capacity.1 GitHub said the October 1 delays started when its cloud provider changed how traffic was routed, which piled API traffic onto a single backend and set off rate-limit errors. Faulty retry behavior in that provider's inventory service made the throttling worse. In a status update, GitHub named an upstream Azure dependency.1

Put together, these explanations point to one weak spot: the seam between GitHub's older datacenters and Microsoft's cloud. GitHub is in the middle of moving between the two. The company's August account said Azure carried about 58% of platform load, up from 12% in May, and handled half of all Git operations.23 Some secondary coverage still cites an older figure of 12.5% on Azure as of March, which shows how quickly the numbers have changed.14 Moving fast lowers the risk of running out of capacity. It also creates new points of failure between on-premises systems and the cloud, and the October 5 incident landed exactly there.

August set the pattern

The clearest picture of GitHub's problem comes from its own account of August 17. That outage lasted 7 hours and 47 minutes and took down github.com, authentication, Actions, APIs, pull requests, issues and Copilot. CTO Vlad Fedorov wrote that traffic hit a new peak and a critical component in GitHub's Central US datacenter failed to scale with it. Then a client-side retry loop pushed traffic higher during recovery. "If you were trying to ship software that day, we let you down," he wrote. He also said that neither the August 6 Actions failure nor the August 17 outage was caused by a code or configuration change. Both, he wrote, were at heart capacity failures.

Secondary reporting added detail that GitHub's blog post left out. It reported that an Istio sidecar hit its concurrency limit while the autoscaling policy was watching the wrong signal. It also reported that a latent retry bug in Visual Studio Code multiplied traffic to one internal endpoint about tenfold, which kept the Copilot Token Service down long after other systems recovered.2123 One postmortem analysis noted that GitHub's own post does not name the failed component or the clients that were retrying, so the more detailed account depends on an incident summary published separately.

GitHub has described the scale of its response. It says it has added more than 3 million CPU cores and 120 petabytes of high-speed storage, and filled its existing datacenters with as much hardware as their power supply allows. It also plans to set consistent retry limits and retry budgets between its internal services. According to reporting, monthly commits roughly doubled from 1.4 billion in April to 2.9 billion.23 Another outlet said COO Kyle Daigle projects about 14 billion commits in 2026, compared with 1 billion in 2025. The same outlet said internal capacity targets rose from a planned tenfold increase to about thirtyfold as traffic from AI agents grew.12

Why AI agents matter here

Coverage broadly agrees on why this is happening: AI coding agents create commits, pull requests and Copilot sessions faster than GitHub's infrastructure was built to handle.1214 A GeekWire profile of Daigle, published two days after the October outage, described the strain from agents as a growing pain alongside GitHub's tighter integration with Microsoft.20 Business Insider has reported that Microsoft is using AWS for emergency GitHub capacity. Microsoft has confirmed only that it uses more than one cloud provider.12

In my reading, this is more than an operations problem. The tools that drive GitHub's growth are the same tools straining it. Agentic workflows and Copilot generate the traffic, and Copilot itself has failed repeatedly, with recent status entries for code review failures and model-provider errors.15 GitHub's August analysis also showed that automated clients retrying too aggressively can turn a partial failure into a full one. As more of the traffic comes from software agents instead of people, the platform's ability to recover depends more on how well those clients handle failure.

What comes next

The frequency of incidents is now as much of a story as any single outage. One tracker counted 72 GitHub incidents between July 11 and October 9, and rated 40% of them major or critical.5 Another reported 17 incidents in the last 30 days and 162 over twelve months.15 These counts come from aggregators with their own methods and should be read as rough guides, not exact audits. Even so, they all point the same way.

Competitors are noticing. Cursor released an early beta of its own code-hosting product during the August outage. CloudBees CEO Moritz Plassnig predicted that GitHub will stop being the default choice as the market splits up.21 GitHub keeps strong lock-in through Actions, its pull request workflow and the open-source community built around it. The October outages show that teams relying only on GitHub-hosted runners have no fallback when things break.

The practical steps for engineering teams are now clear. Teams should keep a self-hosted or secondary runner ready, since self-hosted runners kept working during the October 5 incident.1 They should put retry budgets in their own bots and agents, and check GitHub's status page before spending hours on a problem that is not theirs. GitHub has promised root cause analyses for October 6 and 7.1 Whether those reports point to the Azure migration, to load from AI agents or to something new, they will show whether the capacity investments are catching up with demand.