GitHub has deployed 120 of 160 services in Central US but moved only 13 of 51 primary MySQL databases
GitHub missed its September 30 goal to deploy every production service in Central US, with 120 of 160 there by October 7. Primary MySQL databases are further behind: 13 of 51 had moved, according to GitHub's availability report.
The Engineer · Build desk
Bar comparison of the share of traffic Azure handled for three GitHub workloads: stream-processing traffic 80.2%, core application read traffic 65.4%, Git read traffic 48.3%.
Percent of each workload's traffic handled by Azure
| Item | Value | Claim |
|---|---|---|
| Stream-processing traffic | 80.2% | 3 |
| Core application read traffic | 65.4% | 3 |
| Git read traffic | 48.3% | 3 |
What happened
- GitHub stopped deploying to Central US and adding traffic there on September 11, citing uneven capacity across availability zones.
- GitHub restarted permanent ramps on September 18 and is aiming to unlock all available Central US capacity by the end of October.
- Azure handled 65.4% of core application read traffic, 48.3% of Git read traffic and 80.2% of stream-processing traffic.
Why it matters
- What it limits constraint Until the zone-level capacity work finishes, which GitHub targets for the end of October, further traffic and service moves into Central US depend on it.
- Who's exposed exposure Customers in Central US were hit by the migration's own plumbing, a failover process that fired during a planned handoff.
- Who has to decide decision Anyone tracking progress has to follow services, databases and traffic shares separately, since GitHub says the traffic percentages should not be added.
- What it costs cost The stateful tail is the larger one: 38 primary databases remain, against 40 services, and the databases are the slower moving count.
Counted by service, 75% of the production fleet is deployed in Central US [14]. Counted by primary MySQL database, the share is about 25.5% [15]. That leaves 40 services and 38 databases [16]. A count weighs every service equally, and the report does not break out the traffic behind the 40 that remain. GitHub also warned that its Azure traffic percentages measure different workloads and should not be added [4].
The failover disruption is the instructive incident. An automated emergency process kicked in during a planned database failover, cut off the database copies in Central US and disrupted customers there [8]. GitHub disabled the process during planned handoffs and said it is improving recovery [9].
The September 13 outage had a different cause. It began at 09:16 UTC and lasted 1 hour and 28 minutes [11]. A background cleanup job wrote to a shared database. Its safeguard slowed writes when replicas fell behind, but it did not account for incoming load on the primary, so the primary ran out of connections [11]. Database calls had no quick timeout, so request handlers waited on the stalled database. A retry loop around token creation kept resending writes that were already failing [12].
Each of those three gaps is ordinary. A lag-only throttle, a missing timeout and an unbounded retry are the kind of defects that code review catches one at a time and production finds together.
In our view the containment work is the sturdier part of the report. When a shared dependency fails, half of the pull request traffic GitHub sampled can now keep going with reduced functionality [13]. That is a measured result on a sample, so it transfers only if the sampled traffic resembles the whole.
GitHub's own summary is blunt. "Significant incidents, a capacity pause, and a missed migration target show that the work is not complete," the report says [10]. The report sets the end of October as the goal for unlocking all available capacity [6]. It does not set a new date for the remaining 40 services [16].
What to watch
- Whether GitHub unlocks all available Central US capacity by the end of October, as its report targets.
- The primary MySQL count in the next availability report, which stood at 13 of 51 on October 7.
- Whether a replacement date appears for deploying the remaining 40 production services.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption58
- Hype gap−10
- Incentives
- Not scored
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
By October 7, 120 of 160 production services were deployed in Central US.
- [2]
By October 7, 13 of 51 primary MySQL databases had moved.
- [3]
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.
- [4]
GitHub said the Azure traffic percentages measure different workloads and should not be added.
- [5]
GitHub paused Central US deployments and traffic increases on September 11 because capacity was uneven across availability zones.
- [6]
Permanent ramps resumed September 18 after temporary relief, and durable capacity work continues with a goal of unlocking all available capacity by the end of October.
- [7]
GitHub missed its aggressive September 30 goal to deploy every production service in Central US.
- [8]
During a planned database failover, an automated emergency process disconnected Central US database copies and disrupted customers in that region.
- [9]
GitHub disabled that process during planned handoffs while improving recovery.
- [10]
"Significant incidents, a capacity pause, and a missed migration target show that the work is not complete."
- [11]
The September 13 incident began at 09:16 UTC and lasted 1 hour and 28 minutes. A background cleanup job wrote to a shared database; its safeguard monitored replica lag but did not account for load on the primary, which ran out of available connections.
- [12]
There was no quick timeout on the database calls, so request handlers waited on the stalled database, and a retry loop around token creation kept resending writes that were already failing.
- [13]
Half of sampled pull request traffic can now continue with limited functionality when a shared dependency fails.
- [14]
120 of 160 production services is 75%.
- [15]
13 of 51 primary MySQL databases is about 25.5%.
- [16]
40 services (160 minus 120) and 38 primary MySQL databases (51 minus 13) remained.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- github.blogGitHub availability report: September 2026
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Service reliabilityFollow
- Cloud Migration ProgramsFollow
- Database operations burdenFollow