GitHub's busiest repositories are held out of Azure by a 25ms round trip

GitHub says 99.99999% of its Git repositories now have copies both in its own data centers and in Microsoft Azure, and the few that remain, among the busiest on the platform, are held back by a single 25ms network round trip. In an engineering post on October 21, the company describes how it is changing its write protocol to get them across.

The move itself was forced by growth. GitHub says the agentic shift drove traffic up while its data centers hit a hard ceiling on power capacity in their region, along with supply chain limits.

Half the traffic has already moved

The first repository copy reached Azure's Central US region in August 2025. Most repositories keep five replicas, and most now have two of the five in Azure, which already serves about half of GitHub's Git traffic. Requests are routed to the nearest replica, so traffic moves with the data.

According to GitHub, Azure absorbed most of the growth over that period while its own data centers held steady.

The lock that made every push wait

The problem for the busiest repositories is in Spokes, GitHub's replication system. A write needs only a majority to commit, but Spokes waits for every healthy replica to answer before moving on, and it holds a lock on the whole repository while it does. The slowest healthy copy therefore sets both the speed of each write and how many writes can happen at all.

Azure's target region is about 1,000 miles from GitHub's data centers. Each write needs several 25ms round trips, and a repository already near its limit would fall further behind with every push.

The fix is to lock individual Git references, such as branches, instead of the whole repository. Git only needs each reference to be consistent on its own, and most pushes, from developers and agents alike, go to separate branches. In internal tests with realistic traffic, writes to different references got 3 to 4 times more throughput with lower latency, GitHub says.

Object storage joins the vote

GitHub is also adding a "virtual replica" that writes each change to Azure Blob Storage and counts toward the quorum, so a push is confirmed only once it is stored there. Separate read-only replicas can then be started on demand from that storage. Most repositories see between 100 and 1,000 reads per write, so splitting reads from writes matters.

In load tests, the testing harness reached its own limits before those read replicas did. GitHub says write throughput is the next ceiling and will describe its end-state design at GitHub Universe on October 28 and 29.