GitHub October 2026 availability report: 140 of 151 services now on Azure Central US
GitHub's own report explains each October incident: network failure, a router sending writes to retired databases, and reconnect storms, while the Azure move reaches 32 of 50 MySQL primaries.
· 6 min read
Written by AI from the sources linked below. How we use AI
On this page
GitHub's availability report for October 2026, published on 12 November, lists seven dated incident entries and an extra Azure network disruption on 29 October, and it explains the causes plainly: a partial network failure, a database router that sent writes to retired servers, and a flood of reconnects after a cache failure. The same report says GitHub has now moved 140 of its 151 production services into Azure Central US. Read together, it shows a platform growing fast while its failures keep coming from the same place: one component slows down, clients retry all at once, and the problem spreads.
Key points
- As of 9 November 2026, 140 of 151 production services and 32 of 50 MySQL primaries were running in Azure Central US, according to GitHub.
- The 7 October write outages (about 10 and 9 minutes of failed writes) were caused by a new database-routing machine that started with outdated records listing retired database servers.
- On 30 October a full database connection pool made about 43% of pull request merge attempts fail at the worst point, for roughly 9 minutes.
- GitHub says migrated-service traffic is up 82% since March and that an Actions NAT-gateway change cut usage by 85%.
- The East US 3 buildout is about one week behind plan; its first validated traffic ramp is now due in the first week of December.
What happened
GitHub's report describes the month in two halves. The good half is capacity: GitHub says it more than doubled compute across all nine Central US Kubernetes clusters, that Azure served 63% of migrated-service reads, 66% of monolith reads and 52% of Git reads, and that moving a high-traffic Actions endpoint (more than 250 million requests per day) to a more efficient path cut peak database reads by 85%. Requiring at least three characters before searching repository topics reduced slow or terminated queries for that pattern by approximately 98%.
The other half is the incidents. Here are the entries, in the order GitHub lists them, with the cause GitHub gives for each:
- 5 October (3 h 38 min): GitHub-hosted Actions runners did not pick up jobs. A partial networking failure on the cloud provider's side disrupted connections between one datacenter region and the cloud-hosted databases that the job-assignment service depends on. The service waited for timeouts instead of failing fast, ran out of memory and restarted. Jobs shifted to a healthy region that did not have enough capacity. For about 90 minutes most jobs on GitHub-hosted runners did not start within five minutes. Self-hosted runners were not affected.
- 6 October (3 h 43 min): a surge of migration activity made GitHub Enterprise Importer send very large queries to a shared database and use all its connections. About 1.3% of all requests failed or timed out at the peak, and about 6.4K organizations saw at least one failed or slow request. Migrations were paused until queries were batched smaller.
- 7 October (two incidents, 1 h 11 min and 47 min): write outages of approximately 10 and 9 minutes. During machine replacement, a new machine that manages where database writes go started with outdated records that still listed retired servers, became the leader and published routing settings that sent writes for several core databases to those retired servers. Request failures peaked at 8.9% and 9.3%. GitHub says data already saved was not lost and failed actions succeeded when retried.
- 19 October (1 h 7 min): an internal Actions service lost connections to cache servers in one region; every server retried at once and saturated the network link to that region. About 5% of jobs on GitHub-hosted runners had delayed starts.
- 21 October (4 h 30 min): servers in the event streaming platform ran close to their memory limits, and failed requests opened new connections that used more memory, so the overload spread. Audit log events took about 6 hours 46 minutes to catch up.
- 28 October (1 h 16 min): a credential GitHub uses with an upstream model provider became invalid, and about one in 10 requests to several GPT-family models in Copilot failed. Choosing another model avoided the errors.
- 30 October (31 min): a shared database connection pool ran out. Some update requests held connections while running a slow lookup. Up to about 43% of merge attempts failed at the worst point, compared with about 3.5% of API calls.
Separately, the summary notes an Azure network disruption on 29 October that affected all three Central US availability zones and at least 34,128 signed-in users. The report text we read gives that figure in the summary and does not give the incident its own entry.
Background
GitHub has been moving from its original datacenter to Azure through 2026. The previous report, published on 14 October and covering August and September, said that by 7 October, 120 of 160 production services were deployed in Central US and 13 of 51 primary MySQL databases had moved. It also said GitHub paused Central US deployments and traffic increases on 11 September because capacity was uneven across availability zones, and that it missed an aggressive 30 September goal to deploy every production service there. (The service totals differ between the two reports, 160 then 151, and the report does not say why, so compare the counts moved with care.)
The numbers
The charts below use only figures from the two reports. The first shows how long each incident window lasted, taken from the headings in the October report; the window is not the same as the time customers saw errors, which was often shorter (the 7 October write outages were about 10 and 9 minutes inside windows of 71 and 47 minutes).
| primaries | |
|---|---|
| 7 Oct | 13 |
| 9 Nov | 32 |
Source: GitHub availability reports, September and October 2026
The MySQL count rose from 13 of 51 on 7 October to 32 of 50 on 9 November, according to the two reports in about a month. Several of several of October's incidents sit: database routing on 7 October, a shared database overloaded on 6 October, and a connection pool on 30 October.
What it means
The pattern in GitHub's own descriptions is a retry or timeout storm. On 5 October, calls waited for timeouts and piled up. On 19 October, every server retried at once. On 21 October, new connections used more memory on servers that were already full. On 30 October, connections were held while a slow lookup ran. GitHub lists the fixes it is making: randomised delays on reconnects, limits on how fast services open new connections, backoff for the importer, and earlier alerts on memory and connection spikes.
For developers who depend on GitHub, the practical points are small but real. Retrying a failed push or merge a few minutes later worked in the incidents GitHub describes. Teams that require Actions status checks to merge can be blocked when checks look stuck (21 October). Copilot users could switch model during the 28 October incident, and GitHub says auto model selection reduced the errors. Self-hosted runners were not affected on 5 October.
For GitHub, the report is unusually specific about causes, which makes it possible to check next month whether the stated fixes hold.
What we don't know yet
- Whether the East US 3 buildout will meet the new first-week-of-December ramp date; the report says it is about a week behind.
- How many users the 29 October Azure disruption affected beyond the 34,128 minimum.
- Why the production-service total changed from 160 to 151 between the two reports.
- Whether the 7 October routing safeguards (stronger validation of database routing settings, controls on adding routing machines) prevent a repeat; GitHub says they are in place, and only time will show.
What to watch next
The November report, which should show whether incident counts and durations fall as the remaining services and MySQL primaries move, whether the East US 3 ramp starts in December as planned, and whether the reconnect and connection-limit changes keep retry storms from spreading. GitHub's status page publishes incidents as they happen.
Sources
Written by
The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.
Read next
wfx-loot: 4,837 hijacked GitHub accounts probed 61,764 repos and stole CI secrets
Aikido says stolen GitHub tokens planted a credential stealer in thousands of repositories from 10 November; here is how to check yours and what to rotate.
audiotale.net team8 min read
Azure Linux 3.0.2022 (3.0.20261105-3.0): 470+ CVE references, kernel 6.6.161.1, eMudhra CA removal
Microsoft's Azure Linux release bundles hundreds of CVE references and distrusts roots tied to the eMudhra incident CVE-2026-114406; here is what to update and verify.
audiotale.net team5 min read
Truffle Security's Secrets Revocation Program: 1.4 million leaked API keys still work, 16 issuers join
Truffle says 81% of keys it reported still worked six months later; its free program has issuers revoke leaked keys, and here is what developers should do now.
audiotale.net team7 min read