Agents Pushed GitHub to 7.4 Billion Commits a Month. A Twenty-Year Lock Broke.

GitHub logged 7.4 billion commits in September. A year earlier the figure was a fifth of that, and in 2024 developers pushed about 65 million commits a month.

That growth did not arrive as a curve. It arrived as an outage pattern. GitHub availability, measured as 90 day uptime, bottomed near 84 percent on 7 May, and the reports for the months after it describe a platform still catching up with its own traffic.

A Repo-Wide Lock Is Safe Until the Writers Multiply

GitHub’s Git storage layer is called Spokes. Each repository sits on five replicas, and a write must be acknowledged by a quorum of them. The quorum serializes reference updates with a repository wide lock, so one write holds the lock for an entire round trip, including the network latency to whichever replicas answer.

That turns the quorum into a single unordered queue with one write in flight. Each write costs as long as the slowest healthy replica. With human developers the queue stays short. With agents pushing continuously into the same repositories, the queue grows and every write waits longer than the one before it.

The design was correct where it mattered most. It never acknowledged a write it could not make durable. The problem was throughput, and the fix was choosing a smaller unit of serialization.

Object Storage Became a Member of the Quorum

GitHub moved a copy of 99.99999 percent of its repositories onto Azure. The final fraction is the hardest, because those are the busiest repositories on the platform, and there a 25 millisecond round trip separates a healthy queue from a failing one.

Per reference serialization is what unblocked them. A repository wide lock orders every write. Serializing per reference orders only the writes that contend on the same one. Agents and people working on separate branches stop waiting on each other.

Then object storage joined the quorum as what GitHub calls a virtual write replica. It serves no reads. It holds a write until it is durable in Blob Storage, and it coalesces transactions on unrelated references into one set of network operations, so a busy repository pays one round trip across many concurrent writes instead of one per write.

Once durable state lives in the object store, read replicas no longer need to be quorum members. They warm a cache from storage, take read traffic, and reconcile in the background. Reads scale on their own terms, with their own memory budget.

GitHub’s internal benchmarks put the new architecture at up to 35 times higher write throughput. Alongside it the company has added 4 million CPU cores, 160 petabytes of high speed storage, 50 terabits per second of network capacity, and extra compute for GitHub Actions.

The Limit Was Power Before It Was Software

The timing is the part worth stealing. GitHub says the move was driven by agentic traffic, a hard ceiling on the power capacity of its own data centers and the surrounding region, and physical supply chain constraints. At the start of the migration, remaining capacity plus every possible expansion gave enough time to move safely, but not enough to move slowly.

That is the same wall everyone else has met. A new data center is a grid problem before it is a concrete problem. GitHub could not build its way out of its own footprint, so it rented someone else’s, and it sequenced the work deliberately, moving data first and changing architecture second, because doing both at once under live growth carried too much risk.

For anyone running a quorum replicated store, the lessons are narrow. Measure the scope of what your protocol orders, not only the latency of each node. A lock that covers more than the contending set is a throughput tax on every write.

There is a second order point too. NVIDIA has spent the year prepaying suppliers for capacity that arrives in 2028. Infrastructure now trades in two currencies, cash and allocated capacity. GitHub just showed what happens when the second one runs out inside your own walls.

Three questions for your own platform. What does your write path actually serialize, and is that set larger than the writers that contend? Which of your systems treats object storage as a backup instead of a quorum member? And if your main region ran out of power capacity next quarter, what would you migrate first?