7.38 billion commits in a single month, GitHub is overwhelmed by AI-generated code, and the newly deployed 4 million cores are still far from sufficient.

On August 17, programmers around the world were forced to face a collective outage.

You finished writing the code and hit push, only to see the progress bar stuck in place; automated tests froze, merge requests failed to go through, and even the AI programming assistant Copilot went offline.

This outage lasted for more than 7 hours, and on that day, developers across the globe were waiting for the service to recover.

Three days later, GitHub CTO Vlad Fedorov posted an apology:

If you were trying to release software that day, we have let you down.

He explained the cause: traffic surged to a new all-time high, while a key component in the Central US data center failed to scale accordingly. The pressure spread across the system, causing multiple services to crash one after another.

GitHub defined this incident as a "capacity failure", which was already their second major outage in August.

GitHub official chart: During the August 17 outage, the request failure rate at the entry point once exceeded 50%.

Back in March and April, Fedorov had published posts introducing measures to improve GitHub's reliability. He wrote in his tweets that these efforts are still ongoing to this day.

Just how high has the traffic on GitHub risen?

This September, developers and AI agents submitted 7.38 billion pieces of code on GitHub, more than five times the figure a year ago.

While everyone was marveling at the speed of AI code generation, the GitHub outage brought a problem to the surface: where should all the generated code be stored?

The answer lies in the challenges GitHub has faced in the past six months: the bottleneck of AI code generation has shifted from "being able to write code" to "being able to store it and merge it successfully".

Who is overloading GitHub?

First, let's distinguish between two actions programmers take when writing code:

Commit means saving a local snapshot of your code;

Push means uploading that snapshot to GitHub.

Human programmers usually save a snapshot only after finishing a whole section of code. But AI agents are absolute "saveaholics".

GitHub engineers wrote in the official blog that agents save a snapshot almost after every single step, leading to a skyrocketing number of pushes that has risen 4.9 times, surging from 690 million per month to 3.35 billion.

Back in August, some users on Hacker News raised a point: no matter how many commits there are, what GitHub actually needs to process is pushes, so this metric is inflated.

Someone immediately retorted: "One push with 100 commits consumes more resources than a push with only 1 commit."

What this means is that commits do not reach GitHub until you push, but the more commits packed in a single push, the heavier the workload GitHub has to handle.

Hacker News users debated over whether the number of commits counts as a valid metric.

This retort hits GitHub right where it hurts: agents just love to "save in tiny fragments". The smaller each save is, the more times you save, the greater the pressure on the system.

Worse still, every push is followed by a string of "chain calls": as soon as the code is uploaded, automated tests and code scans will swarm in, pulling the same piece of code over and over again.

In busy repositories, the code can be pulled thousands of times per minute. It's just like you just handed in your exam paper, and thousands of robots rush over to grade it at the same time.

In September, GitHub Actions ran 3.26 billion times, more than 4 times the figure a year ago.

The busyness level varies drastically across GitHub repositories: in August 2026, the busiest single repository received around 1 billion requests. Each upward grid on the vertical axis represents a 10-fold increase in volume.

According to reports from The New Stack, GitHub attributes this wave of growth primarily to "agent demand":

A group of unprecedented new users have arrived. They do not sleep 24/7, and their favorite activity is pressing the save button.

Why do more backups lead to slower storage?

Once you understand how crazy agents are, you will better understand the difficulties of GitHub's old architecture.

To prevent data loss and distribute read traffic, GitHub by default stores 5 full backups for each repository, spread across 5 different servers.

This design was very stable in the era of human developers: you don't have to worry if one backup is lost, and read traffic can be distributed to different servers.

It was with this old architecture that GitHub supported 1 billion code repositories.

But in the era of AI agents, its fatal flaw has been exposed.

The first bottleneck lies in "saving snapshots".

According to the old rules, every time you save new code, all 5 backups need to participate, and the final speed is determined by the slowest server among them.

It's just like a company hires 5 accountants to keep one single ledger, every new entry has to wait for all 5 people to sign off before it is recorded, and the entry is not considered valid until the slowest one finishes signing.

What's more, only one entry can be recorded at a time. If the previous entry hasn't been signed off, the next one can only wait in line. Once more people come to check the accounts, the company has to hire more accountants, but the more accountants you have, the longer the signing process takes.

In the old architecture, read and write operations drag each other down. The more backups GitHub adds to ease read pressure, the slower the snapshot saving process becomes.

Agents are saving snapshots every single minute, and every save has to wait for all the accountants to finish signing.

Even more dangerous, if too many backups fail, the snapshot saving process will stop completely. It's just like if too many accountants fall ill, the ledger can no longer be updated.

The second bottleneck lies in "merging".

All code changes eventually have to be merged into the same main branch.

Within one year, the volume of merges on GitHub has increased to nearly 4 times the original level. It's just like thousands of cars crowding towards the same toll station.

Just how slow is the queue? GitHub engineers did the math in their blog post.

When the backups of one repository are stored in two different locations, the distance between GitHub's own data center and Microsoft Azure is about 1600 kilometers, which takes around 25 milliseconds for a round trip. Saving one single snapshot requires several round trips.

Worse still, the entire repository allows only one write operation at a time. If the previous snapshot hasn't finished saving, the next one can only wait idly.

25 milliseconds is too short for a human programmer to even blink. But for agents, this is the ceiling that locks efficiency: how fast an agent can work depends on how fast a push can complete.

For years, the stability that GitHub was most proud of has turned into a bottleneck in the era of AI agents.

Pouring in more hardware until the data center runs out of power

Facing the traffic peak, GitHub's first reaction was to add more servers.

As of August, GitHub had added more than 3 million new CPU cores and 120 PB of storage.

But an awkward situation still occurred: the data center ran out of power supply.

Fedorov wrote in the post-incident review: they had installed as much hardware as the old data center's power supply could support.

Not only did the data center run out of power, the entire region where the data center is located has reached its power supply limit. All sockets are full, and to add more servers, they have to move to a new location.

As a result, GitHub began to accelerate its migration to Microsoft's cloud platform Azure: in May, Microsoft Azure only took 12% of the workload; by August, this proportion rose to around 58%.

From the start of 2026 to August, the daily completed runs of GitHub Actions rose from around 15-30 million to about 115 million.

At the GitHub annual conference on October 28, the infrastructure figures were updated again:

This year, a total of 4 million new CPU cores, 160 PB of storage (equivalent to around 160 million GB), and 50 Tbps of additional network bandwidth have been added.

But Microsoft executive Jay Parikh still revealed in his blog post that day: simply adding more capacity is not enough, the architecture has to be revamped.

Spending money on more hardware only buys time to catch your breath, it cannot fix the long-standing flaws in the underlying architecture.

Replacing the foundation: separating the ledger from the service counter

How to perform surgery on the architecture? Let's go back to the earlier analogy of the 5 accountants.

In the old approach, each accountant guards one service counter, holding a full copy of the ledger, responsible for both receiving users checking accounts and recording new entries.

The new approach is to store all ledgers in a central repository, leaving the counters to only handle user requests. All code is stored uniformly in Microsoft Azure's large-scale storage, where data loss prevention and backup are fully handled by the storage system. The front-end servers are relieved of heavy burdens and only need to handle incoming requests.

This separation brings three major benefits.

First, read and write operations are separated.

No matter how many people are reading the code, it will not slow down the code saving speed. The front-end counters can be scaled up or down on demand: open more when traffic spikes, close extra ones when traffic drops, and replace a broken server with a new one immediately.

Second, unnecessary signing processes are eliminated.

For one push, the only step that requires full consensus from all nodes is "updating the branch pointer". Moving data into the storage repository, checking data integrity, and scanning for leaked secrets can all run in parallel, no need to wait in line.

Third, back-end cleanup is optimized.

In the past, old data cleanup was done on the same machines that served users, competing for resources with user requests. Now all cleanup tasks are handed over to dedicated "cleaner" machines, which process the data in the background without interfering with user-facing services.

Internal tests show that this new architecture can handle up to 35 times more write operations per second than the old one.

The real challenge is that this major revamp of the architecture has to be completed while GitHub is running normally.

It's equivalent to replacing the engine of a passenger plane while it is flying at an altitude of 10,000 meters.

If GitHub goes down, your agents stop working too

You might wonder: what does GitHub scaling up or down have to do with ordinary developers?

It matters a lot.

No matter what large language model you use, or what agent framework you wrap it in, most of the code generated by the agent will eventually be pushed to GitHub.

On August 17, the day GitHub suffered the outage, Cursor released its own code hosting platform Origin, which was seen by the public as an alternative to GitHub.

But on the same day, Cursor's status page also posted an announcement:

The GitHub outage affected part of Cursor's services, including automation and cloud agents, for 6 hours and 6 minutes.

Cursor status page: On August 17, the GitHub outage affected part of its services, lasting for 6 hours and 6 minutes.

Even if there are alternative code hosting solutions, the workflow of AI agents is still inseparable from GitHub.

That afternoon, a post titled "What are the alternatives to GitHub" on Hacker News received 649 upvotes. Even the code base of the whole industry can fail, so programmers started to seriously look for backup solutions.

What's more surreal is that while GitHub is crowded by agents, it is also building more agents.

At the conference on October 28, GitHub launched a new set of tools that allow agents to work in parallel.

As AI keeps driving down the cost of code generation, bottlenecks will not disappear, they will only move further down the pipeline.

The first bottleneck, "being able to write code", has been solved by large language models. The current one, "being able to store code", is being addressed by GitHub as it revamps its ledger and replaces its underlying foundation.

The next bottleneck will be "being able to merge code".

GitHub engineers themselves admit that the next hurdle is still write capacity. The old methods that brought GitHub to support 1 billion repositories will not be able to carry it to the next billion.

Further down the line, the next bottleneck will be "who signs off on the code".

GitHub laid out a principle in its blog post: the more work agents do, the more capable the code owner must be to review, understand, and make decisions on the code. Unreviewed changes must not be merged into the main branch.

This step is very critical on the path towards ASI (Artificial Super Intelligence).

AI can already write code, but to make it actually deliver working software, the entire infrastructure built for human typing speed has to be completely rebuilt.

GitHub will not be the last service that gets pushed to the wall by this trend.

Microsoft executive Jay Parikh also put forward a bold prediction:

All the software that humans have ever written combined may account for less than 1% of the total software volume that will be generated in the next five years.

If even half of his prediction comes true, when the volume of