GitHub reports eight October incidents amid doubled Azure Central US capacity

Eight incidents across October

GitHub has published its availability report for October 2026, disclosing eight incidents that caused degraded performance across its services. Writing on the GitHub Blog, the company described a month of contrast: a substantial capacity expansion in Azure Central US and several targeted reliability fixes, offset by an October 7 set of write outages that revealed what GitHub calls a hazardous coupling between database orchestration and production routing, gaps in monitoring during data migrations, and an October 29 Azure network disruption that affected all three Central US availability zones and at least 34,128 signed-in users.

Actions queueing stalled by a partial network failure

The first detailed incident began October 5 at 19:11 UTC and ran roughly three hours and 45 minutes. According to the report, users saw Actions jobs on GitHub-hosted runners queue far longer than normal, and some workflow runs never started. During the worst 90-minute stretch, most jobs on hosted runners took more than five minutes to start. Self-hosted runners were unaffected. GitHub Pages sites that build through Actions updated slowly, though already-published sites kept serving, and some customers hit errors in repository lists, licensing and billing pages, and certain Copilot features.

The cause was a partial networking failure on the cloud provider's side, which disrupted connections between one of GitHub's datacenter regions and the cloud-hosted databases behind the service that assigns jobs to runners. Instead of returning errors immediately, the service waited for calls to time out; the accumulated requests exhausted its memory and forced restarts. Jobs then shifted to a healthy region whose assignment service lacked spare capacity and began failing too, while runners that went minutes without work shut down and were slow to replace.

Recovery meant failing over the affected databases and storage one service at a time, adding capacity, and working with the cloud provider to resolve the network problem. Follow-up work includes making job assignment more resilient to sudden load, prioritizing runner assignment by customer profile when capacity is degraded, changing runner behaviour to shorten recovery, and detecting partial network failures faster.

Migration burst exhausted a shared database

The next day, October 6 at 19:57 UTC, a surge of GitHub Enterprise Importer activity sent a burst of very large queries to a shared database and consumed all of its available connections for roughly six minutes. At the peak, about 1.3% of all requests failed or timed out and around 6,400 organizations saw at least one failure, touching sign-in, repositories, pull requests, the API and Codespaces. Enterprise migrations were then paused for about three and a half hours while a fix shipped. Mitigations include fixed-size queries, automated importer backoff when the database is under strain, and new database alerts.

Capacity keeps growing alongside the fixes

As of November 9, GitHub said, 140 of 151 production services and 32 of 50 MySQL primaries were running in Azure Central US, with Azure serving 63% of migrated-service reads, 66% of monolith reads and 52% of Git reads. A compute expansion across all nine Central US Kubernetes clusters more than doubled capacity, and migrated-service traffic has grown 82% since March, absorbed by the new region rather than pushing the original datacenter beyond its prior operating range.

Other changes included a NAT-gateway mitigation that cut usage by 85%, with four production jobs failing during the change compared with roughly 800 expected otherwise, and an Actions endpoint handling more than 250 million requests per day moved to a more efficient service path, reducing peak database reads by 85%. Requiring at least three characters before searching repository topics cut slow or terminated queries for that pattern by about 98%.

The East US 3 buildup is about a week behind plan, with its first validated traffic ramp scheduled for the first week of December, alongside continued work on migration safety, dependency isolation and regional recovery. GitHub reiterates that it prioritizes availability first, capacity second and features after that.

Why it matters

GitHub is effectively the default source-control and CI platform for a large share of the software industry, so when Actions queueing breaks, builds stall across thousands of organizations. The report also illustrates the operational reality of a major cloud migration: capacity is arriving, but several incidents stemmed from interactions between the old and new environments, such as shared databases, cross-region failover and cloud-side network faults. Anyone building on GitHub should read the month as evidence that its reliability depends increasingly on Azure, and that the transition period carries real, measurable risk.