GitHub has been completely disrupted by AI.
On February 9th this year, late at night Beijing time, tens of millions of developers around the world opened GitHub and saw the same page.
It wasn't a 404 error. It was more anxiety - inducing than a 404. It was that yellow warning bar that sent shivers down every engineer's spine, along with rows of indicator lights on the status page that turned from green to red.
github.com went down.
The API went down.
GitHub Actions went down.
Git operations went down - even Copilot wasn't spared.
That night, some people's CI/CD pipelines stalled at the most critical nodes, some people's automated deployments got stuck halfway, and some people were waiting for a PR that couldn't be merged for a long time - behind it was a feature waiting to go live, and real users were waiting.
Afterwards, GitHub released an incident report. In technical terms, the root cause was "an overload of the core database cluster responsible for authentication and user management". But behind these words lies a shocking chain of triggers -
Two days before, in order to push a new model to users as soon as possible, the engineering team changed the refresh time of a "user settings cache" from 12 hours to 2 hours. It was just a change in a configuration number.
As a result, the cache rewrites that were originally spread over 12 hours were compressed into 2 hours, forming a dense "cache rewrite storm". The asynchronous task queue was instantly overwhelmed, the shared infrastructure components crashed, and the chain reaction spread to the service responsible for proxying HTTPS Git operations, ultimately leading to the exhaustion of connections across the entire platform.
A number changed from 12 to 2.
GitHub was brought down by a configuration change it made itself.
But if you only focus on this one configuration change, you probably missed the most important part of this story.
01 It's not one accident, it's ten
The incident on February 9th was not an isolated event.
In fact, in the first three months of 2026, GitHub experienced at least 8 major incidents. In February alone, there were 37 records of various malfunctions. GitHub's CTO, Vlad Fedorov, later admitted in a blog post that in these two months, GitHub failed to maintain the "three nines" - 99.9% availability - promised to enterprise customers.
If you look through the malfunction records of these two months, you'll find a strange pattern: each incident seems to have a different cause.
February 2nd: There was a problem with the Azure computing provider. GitHub Actions stopped working for nearly 4 hours, and Copilot coding proxy, CodeQL, and Dependabot were all affected.
February 9th: A cache rewrite storm led to an overload of the authentication database.
March 5th: There was a failure in the Redis cluster. 95% of GitHub Actions workflows couldn't start within 5 minutes, with an average delay of 30 minutes.
March 18th: The Webhook delay soared to 32 times the normal level.
Each incident seems like an "accident", and the direct causes are all different. But Fedorov's explanation ties them together into the same story. He said that there are three common structural reasons behind these incidents: "rapid load growth, tight coupling between services leading to the spread of local malfunctions, and the system's lack of the ability to protect against abnormal client traffic."
In the words of engineers, the foundation of GitHub has started to show cracks under the heavy pressure of the new load.
And this "new load" has a specific name.
02 275 million commits per week
Key data
Total number of commits in 2025: approximately 1 billion
Number of commits per week in 2026: 275 million
At this rate, the total number of commits in 2026 is expected to be 14 billion (a 14 - fold increase year - on - year)
Computing volume of GitHub Actions: 500 million minutes per week in 2023 → 1 billion in 2025 → 2.1 billion minutes in a certain week at the beginning of 2026
If you were an infrastructure engineer at GitHub, comparing the monitoring dashboards of 2025 and 2026 would probably leave you stunned.
In 2025, GitHub processed approximately 1 billion code commits. This number is already quite large, as it is the result of years of accumulation on the GitHub platform. But in 2026, the number of commits per week reached 275 million. If this rate continues throughout the year, the total number of commits in 2026 will be close to 14 billion, a full 14 times that of 2025.
This is not a smooth growth curve, but a steep slope. The change in the computing volume of GitHub Actions is even more telling: in 2023, it consumed 500 million minutes per week, doubled to 1 billion in 2025, and then soared directly to 2.1 billion minutes in a certain week at the beginning of 2026.
Who is submitting code like crazy?
It's not human developers.
GitHub data shows that AI Agents are becoming the most active "users" on this platform. The Claude Code tool alone now accounts for 4.5% of all public repository commits on GitHub. There are 2.6 million commits per week, while at the end of September 2025, this number was only 100,000 - a 25 - fold increase in three months.
The number of PRs opened by AI Agents is also exploding. In September 2025, the number of PRs generated by AI was approximately 4 million per month. By March 2026, this number had jumped to 17 million - more than four times in half a year.
Here's a picture to help you understand what this means.
In the past, the "users" of GitHub were mainly human programmers. They work during the day, sleep at night, and rest on weekends. They think and hesitate before each commit, and their typing speed has a limit. The system load follows the human work - rest cycle, with peaks and valleys, and is predictable.
Now, more and more "users" are AI Agents. They don't sleep, don't rest, and don't hesitate. One task can start multiple parallel Agents simultaneously. Each Agent can easily submit more code in an hour than a real engineer can in a week. More importantly, they are not only submitting code but also constantly creating new repositories - treating repositories as the "output products" of workflows rather than the "workspaces" of humans.
The infrastructure engineers at GitHub are now facing a problem that is completely different in nature, not just a problem with higher traffic of the same kind.
03 Copilot is running out of money
Frequent malfunctions are just one side of the problem. GitHub has another more headache - inducing trouble - they found they were losing money when doing the accounting.
The initial pricing logic of Copilot was based on a reasonable assumption: users mainly use it in an "assistive completion" mode, each interaction is brief, and the computing volume is predictable. The personal version costs $10 per month, and the business version costs $19 per month, charged per seat. This model has worked well in the past few years.
Then, Agentic AI came along.
Agentic workflows and traditional completion are two different things. In standard code completion, requests are linear and predictable, and the computing cycle is short. However, an Agentic coding session may run for several hours, start multiple parallel threads simultaneously, perform multi - step reasoning, self - correction, and cross - repository refactoring. The number of tokens consumed in one session can easily exceed the monthly subscription fee of an ordinary user.
GitHub is facing a situation where a small number of heavy - using Agentic users are consuming computing resources worth hundreds of dollars with a monthly fee of just a few dollars.
In response to this situation, GitHub took direct action - first, control the flow, and then change the price.
At the beginning of this year, GitHub launched two parallel traffic - limiting mechanisms for Copilot: a session duration limit and a weekly usage limit, both calculated based on the token consumption multiplied by the model's computing weight. At the same time, new user registration for some personal Copilot packages was suspended.
On June 1st, GitHub completed a more fundamental pricing reform: Copilot switched to a pay - per - usage model, replacing the original package fees with "AI Credits". One AI Credit is equal to 1 cent, and the usage is calculated in real - time based on token consumption.
The era of seat - based pricing has come to an end in the face of Agentic AI.
This change is not just a problem for GitHub. It is a collective pricing crisis that the entire AI tool industry is experiencing in 2026 - when AI starts to replace humans in performing complete workflows instead of just "assisting" humans, all subscription logics based on "per person per month" will become invalid.
04 30 times, not 10 times
Let's get back to the infrastructure problem. How exactly is GitHub going to deal with this "14 - fold growth"?
Here's a detail that shows the severity of the problem:
In late December 2025, Agentic workflows suddenly started to accelerate. GitHub's engineers realized that a 10 - fold increase was not enough. By February 2026, after that serious outage, GitHub announced that it needed to redesign the architecture to be 30 times the current scale.
It's not about expansion, it's about a complete redesign.
The difference between these two words is significant. Expansion means adding more machines and increasing the memory of existing databases - the direction remains the same, only the scale gets larger. Redesigning means that the existing architectural assumptions will systematically fail at 30 times the scale, and the way of service splitting, data flow, and fault isolation must be re - thought from the ground up.
The specific directions disclosed by GitHub include decoupling key services to prevent cascading failures, introducing a back - pressure mechanism and traffic degradation capabilities, deploying independent hosts for hot - spot services, eliminating single points of failure, and more comprehensive change management - avoiding actions like "changing the cache TTL from 12 hours to 2 hours" from going live without sufficient stress testing.
It's worth noting that GitHub is not alone.
Stripe has already encountered the problem of AI Agents creating accounts in batches, and AWS is building a dedicated identity system, logging system, and production control mechanism for Agents. These actions are not just precautionary measures; there are already signals on the monitoring dashboards that they have to address.
GitHub is just the first one to be hit hard - because it is at the core of the AI toolchain.
05 Code repositories are becoming AI's exhaust pipes
Stop and think about the nature of the whole thing.
What is GitHub? The most intuitive answer is that it's a place for programmers to store code. But on a deeper level, it is the infrastructure for human software collaboration - commit records are the tracks of collaboration, PRs are the containers for discussions, Issues are the records of intentions, and Actions are the execution pipelines. The entire system is designed for human work rhythms, thinking patterns, and collaboration models.
AI Agents have changed all of this.
When an AI Agent can submit code hundreds of times a day, and there is no human thinking or weighing behind each "commit", just a progress step in a task loop - is the code repository still a "collaboration container"?
When AI tools automatically generate repositories, open PRs, run CIs, and merge - are developers still the main body of this process, or have they degenerated into "reviewers" or even "bystanders"?
GitHub's CTO used the term "rapid load growth" to describe this crisis. But this term may underestimate the essence of the problem - it's not just a quantitative increase, but a qualitative change in the way of use. In the old model, GitHub was a "tool for developers"; in the new model, GitHub is becoming an "exhaust pipe for AI", an output pipeline for automated workflows.
What this means for GitHub actually doesn't have an answer yet. A 30 - fold expansion can solve the traffic problem, but it can't solve the re - definition of the business model, nor can it solve the identity problem of "who is my real user".
Recently, there has been a rather thought - provoking phenomenon: after the outage, GitHub published a large number of engineering blogs, very detailedly describing the root cause of each incident, almost reaching an unexpectedly high level of transparency. Some people think this is GitHub actively building trust, while others think it's an attempt to gain the patience of the developer community with transparency - because there will be more instability during the upcoming reconstruction period.
After being brought down by its own success, a platform needs to be taken apart and rebuilt - and this process itself is also a test of whether it can hold up.
That engineer who was waiting for the PR to be merged on the night of February 9th probably finally got the green light. But he may not have realized that the outage that made him wait was not an accident for GitHub, but a signal that the entire software development industry has entered a new era.
This article is from the WeChat official account “GeekPark” (ID: geekpark), author: Yuhangyuan. Republished by 36Kr with authorization.