GitHub Faces Mounting Infrastructure Pressure From AI Workflows
GitHub is dealing with a sharp rise in infrastructure strain as AI-driven development pushes the world’s largest code hosting platform toward its limits. The company has acknowledged recent availability problems and is now planning for a much larger capacity buildout than it originally expected.
The scale of the change is hard to ignore. GitHub is processing 275 million commits per week, putting it on track for roughly 14 billion commits in 2026. That would be a dramatic increase from the 1 billion commits recorded across all of 2025.
And commits are only one part of the pressure. Weekly compute minutes on GitHub Actions have climbed from 1 billion in 2025 to 2.1 billion in a single week this year. Pull requests opened by AI agents have also surged, rising from about 4 million in September 2025 to more than 17 million in March 2026.
Why GitHub’s 10X Capacity Plan Wasn’t Enough
GitHub had already started working on a major capacity expansion. In October 2025, the company began executing a plan to increase capacity by 10 times.
But by February 2026, that target no longer looked sufficient.
The core reason is a rapid shift in how software is being built. Agentic development workflows accelerated sharply starting in late December 2025, creating demand that quickly outpaced earlier projections. GitHub now estimates that it needs 30 times its current capacity to handle the new load.
That’s the uncomfortable part of the story. The platform wasn’t just seeing ordinary growth. It was absorbing a new kind of usage pattern — one shaped by AI agents generating commits, opening pull requests, and consuming compute at a pace that traditional infrastructure planning didn’t fully anticipate.
GitHub Outages Reveal the Cost of Rapid AI Adoption
The strain has already shown up in visible reliability problems.
GitHub experienced eight major outages in February and March 2026 alone, falling short of the 99.9% availability standard it promises enterprise customers. The incidents continued into April, including one on April 23 tied to a merge queue regression that affected 658 repositories and 2,092 pull requests.
Another incident occurred on April 27, when an overloaded Elasticsearch cluster disrupted search-backed features across the platform. The overload was likely triggered by a botnet attack. An additional service degradation was also flagged on April 29.
For a platform developers rely on all day — to merge code, run automation, search repositories, and coordinate work — these disruptions are more than minor annoyances. They interrupt the basic rhythm of software delivery.
Reliability Gaps Point to Load-Shedding Limits
A key weakness identified in the February incidents was GitHub’s lack of granular controls during crisis response.
The issue comes down to how the platform handles overload. Responders need the ability to selectively shed load when systems are under pressure. Without those controls, the available choices become blunt: deny all requests, or allow infrastructure to keep taking traffic until it starts to fail.
That kind of binary decision-making is risky at GitHub’s scale. When a platform is handling hundreds of millions of commits per week and billions of compute minutes, small failures can ripple across large parts of the developer ecosystem.
GitHub’s Infrastructure Plan for the AI Era
GitHub’s response is broad. The company is working across databases, caches, authentication systems, cloud architecture, and workload isolation.
The planned changes include:
- Migrating webhooks off MySQL
- Redesigning session caches
- Rewriting authentication flows in Go instead of Ruby
- Moving toward a multi-cloud architecture beyond its current Azure footprint
- Isolating critical services like Git and Actions from other workloads
- Improving merge queue performance for repositories handling thousands of pull requests per day
This is not a simple capacity bump. It’s a deeper rethink of how GitHub’s infrastructure should behave when AI agents create far more activity than human developers alone.
Critical Services Get More Isolation
One of the most important parts of the plan is service isolation.
GitHub is separating critical services such as Git and Actions from other workloads. That matters because the most essential developer workflows need to remain stable even when other parts of the platform are under unusual stress.
Git operations and automation are central to how teams use GitHub. If those services are caught in the same failure patterns as less critical workloads, outages can become broader and more disruptive. Isolating them gives GitHub a better chance of protecting the platform’s most important functions during spikes, regressions, or attacks.
Merge Queues Become a Scaling Priority
Merge queues are another focus area.
The April 23 incident showed how fragile this part of the system can become when something goes wrong. A merge queue regression affected hundreds of repositories and more than two thousand pull requests.
GitHub is now investing in merge queue optimizations for repositories that handle thousands of pull requests per day. That’s especially important as AI agents create more pull requests and increase the coordination burden on already busy projects.
When pull request volume jumps from millions to tens of millions in only a few months, merge infrastructure has to evolve with it. Otherwise, bottlenecks form exactly where teams need reliability most: the moment code is ready to move forward.
GitHub Copilot Billing Shifts as AI Costs Rise
GitHub’s AI-driven pressure is not limited to infrastructure. It is also affecting the company’s business model.
GitHub announced that Copilot will move from request-based billing to usage-based billing starting June 1. The company acknowledged that the current model is “no longer sustainable” as inference costs climb.
That pricing change says a lot. AI usage is not just increasing traffic across GitHub’s systems; it is changing the economics behind the products. As developers and AI agents rely more heavily on Copilot, the cost structure has to reflect the heavier compute demand.
Availability Comes Before New Features
GitHub’s priorities are now clear: availability first, then capacity, then new features.
That order matters. When a platform is under heavy pressure, adding features before stabilizing the foundation can make the problem worse. GitHub’s current challenge is to keep core services dependable while expanding capacity fast enough to match the new reality of AI-driven software development.
The company is no longer scaling for a world where human developers are the only major source of activity. It is scaling for a world where AI agents can generate work continuously, open pull requests at much higher volumes, and push infrastructure in ways that weren’t fully visible even a few months earlier.