目錄
GitHub has published a set of numbers that are difficult to ignore: the platform’s monthly commit volume increased from 1.4 billion in April to 2.9 billion today, more than doubling in just four months. The figures appeared in an incident review because GitHub had just experienced a 7-hour-and-47-minute global service disruption on August 17 that affected github.com, Authentication, GitHub Actions, the API, Pull Requests, Issues, and Copilot. GitHub’s public conclusion was straightforward: traffic reached a new peak, while a critical infrastructure component in its Central US data center had not scaled with demand, causing capacity pressure to spread into other services.
The 2.9 billion figure is easy to interpret as “AI Agents have already overwhelmed GitHub,” but the available public data does not support that conclusion. GitHub has not disclosed how many of those 2.9 billion commits were created directly by humans and how many came from Copilot, Claude Code, Codex, or other Agents. Nor has it said that all 1.5 billion additional monthly commits since April were caused by AI. However, GitHub has been discussing rapid traffic growth alongside agentic development workflows since April, and its May Reliability Update explicitly said GitHub traffic was growing rapidly, with a significant portion driven by AI-assisted and agentic development workflows. So it is reasonable to view the surge in commits within the broader adoption of Agents, as long as correlation is not turned into a single-cause explanation.
For developers who use GitHub every day, this is the more important part of the incident. The changes brought by AI coding are starting to appear not only inside IDEs or Pull Requests. Repositories, APIs, Actions, Authentication, Code Review, and the surrounding ecosystem all need to absorb more machine-generated operations. That does not mean the August 17 outage can be directly blamed on AI, but it does show that GitHub itself is redesigning infrastructure for a traffic scale that looks very different from only a few months ago.
GitHub Monthly Commits Increased from 1.4 Billion to 2.9 Billion—What Does That Number Actually Mean?
Twice as Many Commits Means More Platform Activity, Not Twice as Much Useful Code
The figure GitHub published in August shows monthly commits increasing from 1.4 billion to 2.9 billion. In the same chart, GitHub reported roughly 130 million merged pull requests per month and around 24 million new Repositories, with overall activity clearly accelerating between 2025 and 2026.
But a commit is not a unit of software output. One developer might spend three days finishing a feature and commit once, while another might split the same change into ten commits. An Agent may be even more likely to leave many intermediate operations while cycling through fixes, tests, failed results, and further modifications. So 2.9 billion is better understood as the amount of Repository Activity GitHub now needs to process, not as evidence that “global software productivity doubled.”
GitHub also has not published a complete breakdown of human-authored versus agent-authored commits. What can be confirmed is that the company said as early as April that Agentic Development Workflows had accelerated significantly since the second half of December 2025, with rapid growth in Repository Creation, Pull Request Activity, API Usage, Automation, and Large-repository Workloads. Capacity expansion originally planned in October 2025 for a 10× increase had already been revised by February 2026 to design for a future 30× scale.
So the number worth retaining is not “AI wrote 2.9 billion commits,” but that GitHub now genuinely processes 2.9 billion commits per month, and GitHub itself considers Agentic Development one of the important sources of its current traffic growth.
GitHub Itself Does Not Use Growth as an Excuse for the Incident
GitHub makes an important distinction in its incident report: the growth helps explain the pressure on the system, but it does not excuse the outage. That distinction matters because 2.9 billion commits represent demand-side growth, while failing to scale critical components before demand exceeded capacity remains GitHub’s own reliability problem.
That is also why GitHub did not frame the incident report as “there was too much AI traffic, so there was nothing we could do.” Instead, the company directly acknowledged that it had not expanded critical components before demand exceeded capacity and said it would increase capacity, remove architectural bottlenecks, improve Observability, and redesign Service-to-service Retry behavior.
Why Did GitHub Go Down for 7 Hours and 47 Minutes on August 17?
It Was Not Triggered by a Same-Day Deployment, but It Is Also Inaccurate to Say Configuration Played No Role
GitHub’s high-level conclusion was a Capacity Failure, and it stated that the major incidents on August 6 and August 17 were not triggered by a Code Change or Configuration Change made that day. But the Technical Root Cause Analysis provides a more complete picture: a new wave of Peak Traffic first caused Network Saturation in a Central US Load Balancer, one Istio Sidecar Pod reached its Concurrency Limit, and the existing Autoscaling Policy monitored only the Host Service without properly incorporating the Sidecar Limit, so the Sidecar did not scale correctly with demand.
Congestion from one service then spread to other nodes. Eventually, four HAProxy Nodes exhausted their Flow Limits, the Gateway Authentication Path began experiencing latency and failures, and the disruption spread to Issues, Pull Requests, the API, Actions, Git Operations, Copilot, and enterprise authentication features. At the peak of the incident, Web and API Error Rates were around 20%, while Archive and Raw Content Download Error Rates briefly approached 50%.
So “the incident was not caused by a Configuration Change” and “the technical report identified a Misconfigured Policy” are not contradictory. The first means no newly deployed code or new configuration directly broke the service that day. The second means an existing Autoscaling Configuration did not fully account for Sidecar Capacity and had remained hidden under previous traffic levels until the August 17 peak exposed it.
This is also closer to what actually happened than simply saying “GitHub ran out of capacity.” Capacity was the core issue, but the incident expanded because Autoscaling Policy, Load Balancer Flow Limits, Authentication Dependency, and Retry Behavior all hit constraints together, turning a regional load problem into a cross-service outage.
Why Did Copilot Keep Failing Even After GitHub Started Recovering? The Role of the Retry Storm
One Failure Could Be Amplified into Ten Times the Normal Traffic
GitHub disclosed a very specific number in the incident report. After Central US began recovering, some traffic was shifted to Northern Virginia, but an undiscovered Retry Bug in VS Code rapidly generated additional Requests whenever a Copilot Token Operation failed. The result was that normal Copilot Token Service traffic of 7,000–9,000 RPS was amplified to 70,000–100,000 RPS, close to ten times normal volume.
This is why “the service is recovering” does not mean traffic immediately returns to normal. When large numbers of Clients receive errors at the same time, each may Retry immediately, while the Gateway, Client, and other Services may each have their own retry logic. A design intended to increase the success rate of an individual Request can instead create far more traffic than normal during an incident. GitHub eventually had to reduce Gateway Authentication Retries and even temporarily return 403 responses to some Copilot Token Requests so the Retry Loop would stop before traffic was gradually restored by region.
The Retry Storm is more important than the simplistic idea that “AI never gets tired, so it keeps retrying,” because retry storms are not unique to AI. Traditional Clients, Microservices, and automation systems can all produce them. What Agent adoption changes is the number of machine operations and the amount of Fan-out. One human Intent may generate multiple Tool Calls, API Requests, Repository Operations, Tests, and follow-up fixes. Without Concurrency Limits, Backoff, and an overall time budget, this traffic can be amplified faster and become harder to control than ordinary manual activity.
How Is GitHub Planning to Fix This? Not Just More Servers, but Limits on Cascading Load
Autoscaling, Retry Budgets, and Regional Failover All Need Changes
GitHub’s Technical RCA lists several follow-up actions: fix the Autoscaling Policy so Service Mesh Sidecar Concurrency and Capacity are properly included in scaling decisions; review related services for Istio Request, Concurrency, and Scaling Limits; revisit Gateway and Client Retry Limits and Backoff Behavior; fix the VS Code retry issue that amplified Copilot Token Traffic; and improve Load Balancer Capacity Monitoring and Regional Failover Safeguards.
GitHub’s CTO also used another term worth noting for development teams: Retry Budget. GitHub plans to apply consistent Retry Limits, Retry Budgets, and Variable Timeouts across Service-to-service Interaction so individual services do not keep retrying from their own perspective until they collectively overwhelm downstream systems.
A Retry Budget is quite different from simply saying “retry three times after failure.” If one downstream service is overloaded and one thousand Callers each assume that a few more attempts will improve reliability, total traffic only rises further. A Retry Budget instead treats retries as a limited resource. When the system is already failing at scale, some Requests should Fail Fast rather than trying to rescue every individual operation and dragging the entire service down with them.
GitHub Has Already Been Adding Huge Amounts of Capacity—Demand Is Just Growing Even Faster
GitHub did not wait until August to start adding hardware. The company says this year’s Reliability Work has already added more than 3 million CPU Cores, 120 PB of High-speed Storage, and substantial Network Capacity, while continuing to migrate services toward Azure. Azure now handles about 58% of GitHub’s Platform Load and roughly half of Git Operations, compared with only around 12% of Platform Load in May, indicating a very rapid migration.
But these figures also show why Agentic Software Development is difficult for infrastructure teams: the demand curve itself is still changing rapidly. GitHub planned for 10× capacity last October, began designing for 30× only a few months later, and monthly commits then jumped from 1.4 billion to 2.9 billion between April and August. Capacity planning can no longer be reduced to multiplying today’s usage by a fixed growth rate.
How Is AI Agent Traffic Different from Traditional Developer Traffic?
The Difference Is Not That “AI Never Sleeps,” but That One Task Can Expand into Many Machine Operations
It is intuitive to distinguish the two by saying “humans sleep, AI does not,” but that oversimplifies the problem. GitHub Actions, CI Bots, Dependabot, and other automation services have already been running 24 hours a day for years. GitHub is not encountering non-human traffic for the first time.
The more significant change Agents introduce is Fan-out. A person may enter a single instruction such as “fix this Bug,” after which the Agent reads the Repository, creates a Branch, modifies several files, runs Tests, checks Failure Logs, modifies the code again, Pushes, opens a Pull Request, and then continues another cycle based on Review or CI results. GitHub itself linked rapid growth in Repository Creation, Pull Request Activity, API Usage, Automation, and Large-repository Workloads with the expansion of Agentic Development Workflows in its April and May Reliability Updates.
So the future challenge may not simply be that “someone is also Pushing at 3 a.m.” It is that one user Intent may generate far more API Calls, Git Operations, Actions Runs, and Review Activity than before, with those actions happening simultaneously, retrying quickly, and potentially being executed in parallel by many Agents.
AWS Expanded GPT-5.6 Cross-Region Inference in the Same Week, Addressing the Other End of Agent Traffic
Amazon Bedrock expanded API support for GPT-5.6 Sol, Terra, and Luna that day, allowing all three models to be accessed through bedrock-runtime using Responses, Chat Completions, and Converse APIs. AWS also added Global and Geo Cross-Region Inference, allowing Requests to be automatically routed across multiple AWS Regions to obtain higher Throughput.
This should not be described as “GPT-5.6 is now directly deployed in more than 25 AWS Regions.” Sol’s In-region Availability is currently concentrated in US East, including N. Virginia and Ohio, while Terra and Luna additionally have US West availability in Oregon. Cross-Region Inference instead uses Inference Profiles to route Capacity among eligible Regions. On August 18, AWS separately added India Geo Cross-Region Inference for Terra and Luna, allowing data to remain within the Mumbai and Hyderabad geographic area during processing.
Putting AWS and GitHub together makes for an interesting upstream-and-downstream comparison from the same week, but there is no direct causal relationship between the two companies. AWS is solving the problem of routing high-demand model inference across Regions to find Capacity, while GitHub is dealing with rapid growth in Repository, Actions, API, and other Developer Infrastructure demand. What both illustrate is that Agentic Workloads are forcing platforms to rethink Throughput, Burst Traffic, and capacity scheduling. When launching GPT-5.6, AWS itself described Agent Traffic as often highly Bursty, with one User Request potentially generating a large number of Model Calls.
What Safeguards Should Development Workflows Add When Using AI Coding Agents?
Keep a Working Local Git Repository
Git is a Distributed Version Control system, so a normal local Repository already contains Branches, Commits, and most of the working history. When GitHub is unavailable, Local Commit, Branch, Merge, and local testing can usually continue. The parts most likely to be blocked by a GitHub Outage are Pull Request Review, Issues, GitHub Actions, Webhooks, Authentication, and Deployment Workflows that depend on the GitHub API or Hosted Runners.
So rather than simply keeping another Git Client installed, it is more useful to ask how much work remains possible outside GitHub. If a GitHub outage for one afternoon prevents even local testing from running, the workflow may have tied too many essential steps to a Remote Service.
Do Not Configure Agent Retry Logic as Simply “Try Again If It Fails”
If a self-built Agent, Script, or Automation calls the GitHub API, it should at minimum have a maximum Retry count, Exponential Backoff, Jitter, and an overall Deadline, while also respecting Rate Limit and Retry-After signals returned by the service. GitHub’s Copilot Token Service jumping from a normal 7,000–9,000 RPS to 70,000–100,000 RPS is an extreme reminder that Retry is meant to improve success rates, but without total-volume controls it can become an incident amplifier instead.
Coding Agents can add another layer of Concurrency Limits—for example, the maximum number of Agents allowed to run simultaneously against the same Repository, the maximum number of Pushes per minute, or how many automated repair cycles are allowed after a CI Failure before the process stops and hands control back to a person. That is usually more controllable than allowing the Agent to retry indefinitely.
You Do Not Need to Squash Every Commit Just to Save GitHub Capacity
There is currently not enough evidence to recommend Squashing every small Agent-generated Commit before Push simply to “reduce GitHub write pressure.” Whether Commit History should be Squashed should still depend on Review, Bisect, Rollback, and the team’s Version Control Policy.
What is more useful to control is the frequency of Pushes, PRs, and CI. An Agent can complete several rounds of changes and tests on a Local Branch before Batch Pushing once, rather than triggering a new Remote Event, Webhook, and CI Run after every minor edit. If the team wants Main Branch history to remain concise, it can still use Squash Merge according to its normal practice. This reduces automation Churn without sacrificing useful development history simply to reduce the number of commits.
GitHub Status Can Be Built Directly into the Incident-Confirmation Workflow
GitHub Status continuously updates recovery information for Issues, Pull Requests, Actions, API, Git Operations, and Copilot, and the Status Page itself supports Email, SMS, Slack, Webhook, Atom, and RSS subscriptions. For teams that depend on GitHub every day, putting the official Status Feed into an existing notification system is more useful than spending half an hour reinstalling Git or checking the Router whenever errors appear.
Small teams do not need to build a large monitoring platform either. At minimum, keeping the official Status pages for GitHub, primary model APIs, the deployment platform, and cloud providers easy to check in one place can eliminate a significant amount of unnecessary local troubleshooting.
When Reviewing Single Points of Failure, Do Not Look Only at the Git Repository
Git Repositories are relatively easy to keep as Local Copies. The parts of GitHub that are harder to replace are usually the surrounding services: Pull Requests, Code Review, Issues, Actions, Secrets, Branch Protection, Packages, Webhooks, Deployment Approval, and third-party Integrations.
A useful question is therefore very concrete: if GitHub went down from morning until evening, what could still continue normally and what would stop completely? If a Repository has a strict Recovery Time Objective, then a Secondary Remote, Mirror, or alternative CI path may be worth considering. For an ordinary personal project, knowing that local work can continue and Pushes can wait until the service recovers may already be sufficient. Redundancy itself has maintenance costs, so not every project needs dual-platform high availability.
What This GitHub Incident Reveals Is Not Simply That AI Is Writing More Code
GitHub’s 2.9 billion monthly commits are a huge number, but they are not an AI productivity leaderboard and cannot prove that software output doubled in four months. What can be said with more confidence is that GitHub platform activity is increasing extremely quickly, and the company itself has repeatedly stated that AI-assisted and Agentic Development Workflows are important sources of this growth.
A new traffic peak encountered an Autoscaling Policy that did not properly scale with Sidecar Capacity, followed by Load Balancer Flow Limits, Authentication Dependency, and Retry Amplification. Together, those conditions turned localized capacity pressure into a 7-hour-and-47-minute cross-service incident.
For developers who use Coding Agents every day, a more practical question than how many of those commits were written by AI is what happens after coding becomes cheaper and more automated. Pushes, CI, Review, API usage, Deployment, and Retries may all increase along with it. How quickly an Agent can produce the next version of the code is only the first half of the process; whether the infrastructure behind it can reliably absorb all those operations is now becoming part of the development workflow too.
FAQ
There is currently not enough evidence to make that conclusion. GitHub confirmed that monthly commits increased from 1.4 billion in April to 2.9 billion and has publicly said that recent traffic growth is being driven in significant part by AI-assisted and Agentic Development Workflows. However, it has not disclosed how much of the August 17 Peak Traffic came from AI Agents and has not said Agents were the single cause of the incident. The direct technical causes were capacity pressure in Central US and subsequent cascading failures involving Autoscaling, Load Balancers, and Retry behavior.
GitHub means that no newly deployed Code or Configuration Change triggered the incident that day. However, the Technical RCA does identify an existing Autoscaling Policy that monitored only the Host Service without correctly accounting for the Istio Sidecar Concurrency Limit, so scaling did not respond properly when Peak Traffic arrived. The more accurate description is that “no new configuration change triggered the outage, but the existing Autoscaling Configuration contained a gap.”
No. The 2.9 billion figure represents the volume of commit activity GitHub currently processes each month. It cannot be directly converted into useful code volume, software output, or developer productivity, and GitHub has not published the share attributable to humans versus AI Agents.
Not simply to reduce GitHub platform load. Whether commits should be preserved depends on the team’s Review, Bisect, and History Policy. If the goal is to reduce remote operations caused by an Agent, it is more practical to let the Agent complete several rounds of local changes before Batch Pushing and to control the frequency of PR, CI, and Retry triggers.
In most cases, yes. Git is a distributed version control system, so a local Repository can continue to Commit, create Branches, Merge, and inspect history. The parts that fail are mainly those requiring GitHub Servers, including Pull Requests, Issues, Actions, API access, remote Push／Pull, and other Hosted Services.
No. AWS announced Cross-Region Inference support for GPT-5.6 Sol, Terra, and Luna on August 17 so model Requests could be routed across multiple Regions for greater Capacity and Throughput. GitHub, meanwhile, was handling rapid growth in its own Repository, API, Actions, and related Developer Platform traffic. The two stories can be compared as examples of how Agentic Workloads are affecting infrastructure capacity, but AWS increasing upstream model capacity did not directly cause GitHub’s downstream outage.