AI Agents Are Breaking the Internet. The Numbers Are Staggering.

Alright. Sit down. Let me tell you what's actually happening.

In February 2026, GitHub logged 37 separate incidents. Thirty-seven. In one month. The Wayback Machine shows they averaged 1 to 4 incidents per month back in 2019. So that's roughly a 10x degradation in platform reliability for one of the most critical pieces of infrastructure in software development. Their own Enterprise SLA promises 99.9% uptime. Third-party trackers put their actual uptime at 90.21% over the last 90 days. That's one nine. Not three.

Meanwhile, Claude went down on February 24th, then again on March 2nd, then again March 3rd — two consecutive days — then again on April 6th and 7th. Downdetector logged spikes of 4,700 user reports during the February incident alone, with HTTP 500 and 529 errors hitting across the web interface, Claude Code, and the API.

ChatGPT spent 15+ hours offline in June 2025. During that incident, Sam Altman reportedly joked the team's GPUs were "melting." Then in December 2024, an Azure datacenter power failure knocked ChatGPT offline for 9 hours. Then in November 2025, a Cloudflare outage took down both ChatGPT and Sora simultaneously, affecting — and I want you to really read this carefully — an estimated billions of global users during peak disruption.

This isn't bad luck. This isn't growing pains. This is a structural problem that the industry walked directly into, and the root cause is sitting in your terminal right now running claude --continue.

The Number That Should Break Your Brain

GitHub COO Kyle Daigle posted some numbers on April 7th that deserve more attention than they got. The platform logged roughly 1 billion commits across all of 2025. It is now seeing 275 million commits per week. If that pace holds, GitHub processes more code in a single month of 2026 than it did in all of 2024.

That's not 14 times more developers showing up. According to GitHub's own Octoverse 2025 report, new developer signups haven't spiked anything close to that. The commits are coming from agents. Claude Code's weekly commits to public projects grew 25-fold in six months — from around 100,000 commits per week to over 2.5 million by late March 2026. AI-agent pull requests jumped from roughly 4 million in September 2025 to over 17 million by March 2026, per reporting from The Information.

GitHub Actions usage went from 500 million minutes per week in 2023, to 1 billion in 2025, to 2.1 billion as of early April 2026. A quadrupling in three years for a service already running at enormous scale.

Here's the thing that makes this qualitatively different from normal traffic growth. A human developer does the commit-PR-CI cycle maybe two or three times a day. An AI coding agent does it every few minutes. And it does it in parallel. Multiply that behavior across millions of developers now running Claude Code, OpenAI's Codex CLI, Cursor, and the growing zoo of open-source alternatives, and you stop having a "traffic growth" problem. You have a traffic character problem. The shape of the requests changed entirely, and the infrastructure wasn't designed for this shape.

What's Actually Failing and Why

Let's get specific. Because "the servers are overwhelmed" is vague, and you deserve better than vague.

GitHub's Cache Catastrophe

GitHub's March 2026 availability report is a brutal read if you understand what you're looking at. On March 3rd, github.com request failures hit approximately 40%. At the same time, 43% of GitHub API requests failed. The root cause: a large volume of writes to the user settings caching mechanism caused a bug where every user's cache expired simultaneously, forcing the system to recalculate and rewrite every cached entry at once.

That's a cache stampede. You've probably read about this in distributed systems contexts as a theoretical failure mode. GitHub ran into it in production at scale because AI agents were hammering the user settings endpoints at a rate no one had engineered for. The fix for the original write volume apparently introduced the bug that blew the cache. Two incidents, same underlying cause.

On March 5th, a Redis load balancer misconfiguration during infrastructure updates routed internal traffic to the wrong host. Actions went down. 95% of workflow runs failed to start within 5 minutes, with an average delay of 30 minutes and a 10% hard failure rate. GitHub's own post-mortem noted they're now working on alerting to catch misconfigured load balancers before they become incidents. After the fact. As you do.

Then on March 19th and 20th, the Copilot Coding Agent service hit a system authentication issue that prevented it from connecting to its backing datastore. During the second incident, error rates peaked at 100% of requests — with "significant retry amplification." That phrase is doing a lot of work. Retry amplification means the failing clients kept retrying, which generated more load on an already overwhelmed system, which caused more failures, which caused more retries. A death spiral triggered by authentication infrastructure that couldn't handle the connection volume.

Claude's Capacity Wall

Anthropic's situation is different but the underlying dynamic is the same. Claude hit number 1 in U.S. App Store downloads in late February 2026, surpassing ChatGPT. That came with a wave of user migrations driven partly by the backlash against OpenAI's Pentagon contract. More than 1.5 million users signed a pledge to boycott ChatGPT. A non-trivial chunk of them went to Claude. Anthropic's infrastructure met that surge and, at least for the frontend and authentication layers, flinched.

The March 2nd outage began at 11:49 UTC and took out authentication flows worldwide. Claude Code became completely inaccessible. The API — running on Anthropic's backend — stayed functional. So the GPU cluster serving inference was fine. The web infrastructure between users and those GPUs couldn't handle the load.

Anthropic acknowledged the problems within 17 minutes, which is actually impressive compared to how OpenAI handled their June 2025 outage. But acknowledging the problem fast doesn't fix it. When the same platform went down again on March 3rd — less than 24 hours later — and again in April, you have to conclude there's a capacity ceiling that hasn't been raised fast enough to meet demand.

The April 6-7 incidents specifically hit Claude Opus 4.6 hardest, which is the most compute-intensive model in the lineup. More people running the biggest model more often. The math on that is unforgiving.

ChatGPT's Azure Dependency Problem

OpenAI runs ChatGPT on Microsoft Azure. I'll let that sink in for a second given everything we wrote about the Microsoft vs. OpenAI relationship — a company increasingly at war with its infrastructure provider is still completely dependent on that provider's uptime.

The December 2024 outage was a datacenter power failure. Azure went down, ChatGPT went down, OpenAI couldn't do anything about it. The June 2025 outage was demand-driven — 800 million weekly users, a viral use pattern, and GPU clusters that hit capacity. OpenAI serves approximately 100 million ChatGPT requests daily across roughly 128,000 GPUs. The difference between naive load balancing and intelligent load balancing on that scale is literally millions of dollars in infrastructure costs and the difference between 50ms response times and 500ms response times. When the traffic type changes — longer prompts, more context, agentic loops that generate 10x the token volume of a simple Q&A — the existing load balancer configuration becomes wrong without anyone changing anything.

Load Balancers

Let me get into the weeds here because this is where it gets genuinely interesting.

Traditional load balancers think in terms of requests per second. Round-robin, least-connections, weighted round-robin — these algorithms distribute incoming requests across a pool of backend servers. They work fine when requests are roughly uniform. An HTTP request to load a webpage takes a predictable amount of time. A database query has a bounded latency profile.

LLM inference doesn't work like this. The processing time varies by a factor of 100 or more based on input sequence length. A short prompt might return in 50ms. A long-context prompt with a 128,000-token context window might take 2-3 seconds per response, and that's on dedicated hardware. An agentic workflow — where the model is reading files, generating code, running tests, reading the output, and iterating — doesn't send one request. It sends dozens, each with growing context, each occupying GPU memory for the duration.

When a load balancer treats all these requests as equal and routes them round-robin, you get a brutal distribution problem. One GPU server gets assigned three 60-second agent sessions simultaneously. Another server gets assigned 200 fast Q&A requests. The first server falls behind its queue and users see timeouts. The second server is 30% utilized. Your overall cluster throughput tanks even though hardware is sitting idle.

The fix is queue-depth balancing — routing based on estimated completion time rather than raw connection count. Anthropic uses queue-depth balancing for Claude serving, but even that breaks down when the traffic volume grows 25-fold in six months. You can have the right algorithm and still have insufficient capacity.

For GitHub specifically, the problem is that Actions and Git operations shared failure domains. A Redis misconfiguration that breaks the Actions queue manager also degrades Git push operations because they share infrastructure dependencies. The March incidents led GitHub to explicitly commit to isolating key dependencies so Actions and Git don't share failure domains. That's a good fix. It also should have been designed that way from the start.

The Bandwidth Bill Is Going to Be Obscene

Here's where I have to just rant for a minute, because I've been running servers since 2010 — first at SolidShellSecurity, then at VPSNode — and the bandwidth and infrastructure cost implications of what's happening right now are genuinely staggering to me.

An AI agent cloning a repo isn't a human pulling 50KB of diffs. It's cloning the full repository, potentially gigabytes of history, every single session. It's reading hundreds of files for context. It's pushing commits, triggering CI/CD pipelines that spin up fresh container instances, run full test suites, produce artifacts, and then those artifacts get pulled down by other agents downstream for review. Each of those steps costs bandwidth. Each CI pipeline job costs compute-minutes.

GitHub Actions usage hit 2.1 billion minutes per week as of early April 2026. At GitHub's standard rate of $0.008 per Linux minute for paid usage, that's approximately $16.8 million per week in compute alone if every minute were billed at list price. That's obviously not how GitHub's pricing works at scale — enterprise and included-minute tiers change the math significantly — but the volume is real, and the infrastructure that processes those 2.1 billion minutes has to exist somewhere.

Every CI run spins up a container. That container has to be pulled from a registry, initialized, have the repo cloned into it, run the job, push artifacts, and then be torn down. The container image pull alone is a network operation that, multiplied by billions of runs per week, becomes a bandwidth number that would have seemed absurd three years ago. GitHub is now engineering dedicated caching infrastructure just for this — so container images aren't being pulled cold from registries on every run.

The retry amplification problem I mentioned earlier is also a bandwidth multiplier. When your Copilot Agent sessions hit a 99% error rate, clients retry. Clients on exponential backoff still generate retry traffic. If your authentication service is failing because it's overwhelmed by connection volume, adding retry traffic from failing clients pushes it further over capacity. You need circuit breakers. You need bulkheads. You need shedding logic that returns a clear 503 with retry-after headers rather than timing out, because a timeout generates more retries than a clear rejection.

Most of these platforms were built for human-speed usage. Humans have latency. They read the response. They think. They type. Between a human's keystrokes, the server gets a break. An AI agent in a loop has no latency between iterations. It finishes one API call and fires the next one immediately. The request rate per "user" went up by orders of magnitude without the user count changing materially.

I ran into a smaller-scale version of this at VPSNode. When automated crawlers and monitoring scripts started running against customer VPS instances more frequently than human traffic, the load patterns on shared infrastructure looked completely different from what we'd capacity-planned for. CPU utilization spikes that should've been smooth across the day started looking like square waves — full load for 30 seconds, zero load for 10 seconds, full load again. Load balancers configured for smooth traffic don't handle square waves well. You get timeouts at the load balancer level before the backend server is even close to capacity, because the connection queue fills faster than the balancer can route.

Imagine that problem at GitHub's scale. Millions of agents firing requests in tight loops, no natural human pacing. The load doesn't grow gradually during business hours and taper off overnight. It's continuous, it's bursty, and it comes from every timezone simultaneously.

We covered the CPU-side of this infrastructure crunch already — go read The CPU-ocalypse Is Here if you want to understand how the chip shortage is compounding this. The GPU story gets all the attention. The CPU bottleneck and the networking bottleneck are the ones that are actually biting right now.

The Cascading Dependency Problem

This is the part that should concern you personally, as a developer who may be using these tools for your work.

When GitHub went down on February 9th, it didn't just mean developers couldn't push code. It meant Claude Code couldn't push code. It meant Copilot agents couldn't open PRs. It meant CI pipelines — which feed back into agent workflows — went dark. An AI-augmented development workflow isn't one tool. It's a chain: LLM → Git host → CI runner → artifact storage → deployment system. Each link has its own uptime. Chain them together and you multiply the failure probability.

Claude Code commits to public projects grew 25-fold in six months. Those commits trigger Actions workflows. Those Actions workflows run code that might call Claude or OpenAI APIs for additional processing. When Claude goes down, some of those workflows fail. Those failures generate retries. Those retries generate additional load on GitHub's infrastructure. The failure of one platform propagates load and failures into others.

We're building dependency graphs between AI services that no one has mapped. When Cloudflare went down in November 2025 and took ChatGPT with it, it also took down AI-dependent services that ran on Cloudflare's network but had nothing to do with OpenAI directly. The failure domain was enormous and nobody had a complete picture of it beforehand.

I've been watching this pattern develop. Back when r/programming banned LLM discussions in April, part of the frustration driving that decision was how thoroughly AI tooling had embedded itself into every development conversation. That embeddedness isn't just cultural. It's structural. The tools are now dependencies. Dependencies fail.

Amazon's bet on Kiro AI and the broader enterprise push to make agents central to engineering workflows is adding another layer to this. Enterprise deployments don't scale linearly with user count — they scale with agent concurrency. One developer with Kiro AI running in agentic mode might generate the API traffic of 50 developers doing things manually. The enterprise sales pitch is productivity. The infrastructure implication is a demand curve that behaves nothing like historical usage data.

What Torvalds Noticed That Everyone Else Missed

Linus Torvalds flagged something in Linux 7.0 RC6 that's relevant here. He saw more patch volume than he expected this late in the release cycle and suspected AI coding tools might be partly responsible for the noise. He wasn't wrong. When more people can generate patches — because the barrier to creating a diff dropped significantly with AI assistance — more patches flow into review queues. Reviewers get overwhelmed. Quality control degrades. The infrastructure for reviewing code wasn't designed for AI-generated throughput any more than GitHub's backend was.

GitGuardian's 2026 Secrets Sprawl report found that AI-assisted commits leak credentials at roughly double the baseline rate. More commits, higher error rate per commit, running continuously. Every leaked credential is a potential incident. Every incident generates traffic to status pages, which go down because developers flood them looking for updates, which generates more traffic. The failure modes cascade in directions nobody anticipated.

The Fix Requires Admitting the Problem

GitHub has at least acknowledged the scope of what they're facing. Their March post-mortem committed to redesigning the user cache system, auditing critical infrastructure capacity, and isolating failure domains so Actions and Git operations don't share blast radius. Those are the right moves. They should've been done 18 months ago before agent traffic went vertical.

Anthropic needs to separate its frontend authentication infrastructure from inference capacity so a surge in new user signups doesn't take down paying enterprise customers who are hitting the API directly. That architectural separation is basic. The fact that the API stayed up during the March 2nd outage while the web interface collapsed means the backend is fine. Fix the frontend.

OpenAI's Azure dependency is a harder problem. You can't untangle years of infrastructure investment quickly. The OpenAI-Microsoft relationship is complicated enough that OpenAI has been quietly diversifying toward Amazon infrastructure, but those migrations take time, and every day they're still single-cloud is a day one datacenter power event can take down 800 million users.

For you as a developer: stop treating any of these platforms as a single-tenant reliable dependency. Build failover logic. Keep local model options available for when the cloud is down. If your CI/CD pipeline calls an LLM API, give it a circuit breaker. If your agent workflow depends on GitHub Actions, know what you'll do when Actions is running at 30% failure rate for an entire afternoon.

Anthropic accidentally leaked the entire Claude Code source in March — which is a different kind of infrastructure failure but reveals the same thing: these organizations are moving too fast for their own operational hygiene. Fast growth and operational discipline are genuinely difficult to maintain simultaneously. They're not pulling it off perfectly.

The Part Where I Get Annoyed

Look, I've been building web infrastructure since before most current developers started writing code. I started on Perl because ProBoards used it. I ran hosting companies. I've watched the traffic curves on shared servers when bot traffic starts mixing with human traffic and the load profile turns into something the hardware never expected.

The bandwidth story here is the one that should be making executives nervous and isn't getting enough column space. AI agents don't sleep. They don't take lunch. They don't get distracted by Slack. They run at wall clock speed, all day, every day, generating network traffic with no natural pacing. Human traffic has a daily curve — it builds during morning hours, peaks midday, tapers at night. Bandwidth provisioning and load balancer configuration assume that curve. When your traffic source is global AI agents operating continuously, the curve flattens. You need 24/7 peak capacity instead of provisioning for average load with headroom for peaks.

The cost of that is not small. Bandwidth is not free. Compute minutes are not free. Redis clusters that can handle a cache stampede from 100 million simultaneous users are not something you bolt on after the fact. These platforms are now discovering that their infrastructure economics — designed around human usage patterns — don't survive contact with agent-scale traffic.

The irony is that AI agents like the ones now breaking GitHub were partly built to make developers more productive. They're working as designed. The productivity gains are real. The infrastructure wasn't scaled to absorb those gains, so the gains generate new costs and new outages that eat into the productivity advantage.

Meta ran internal "tokenmaxxing" contests to see which developers could generate the most token volume using AI tools. That's a real thing that happened in 2026. Token volume as a metric of productivity. Think about what that does to the infrastructure bill of the AI providers those tokens are hitting. Think about what it does to GitHub's Actions queue when the code those tokens produce all gets committed and tested simultaneously.

At some point, the industry needs a conversation about what "AI-augmented development" actually costs per engineer at scale. Not the licensing cost. The full infrastructure cost: bandwidth, compute, storage, the load balancer capacity to handle non-human traffic patterns. That conversation isn't happening at the rate it needs to, and the outages we're watching now are the market's way of forcing it.

Where This Goes

The platforms are going to fix the acute problems. Cache stampede protections. Better isolation between failure domains. More capacity. They have the financial resources to do it, and the outages are expensive enough to their businesses that they're motivated.

The deeper issue is that the whole industry is running a capacity planning model built on historical human traffic patterns, and those patterns are now obsolete. The transition from human-paced to agent-paced traffic happened faster than anyone planned for, and the infrastructure debt from that mismatch is getting paid in downtime.

GitHub's numbers don't stabilize at 275 million commits per week. Agent tooling keeps getting faster, more autonomous, and more widely deployed. Daigle said he doesn't expect the trajectory to stay linear. He's right. It won't stay linear because it'll either accelerate further as agents get better, or it'll plateau when the infrastructure collapses often enough that people lose confidence in the tools. Neither outcome is particularly comfortable.

For the platforms building on top of this infrastructure: resilience is not a nice-to-have anymore. Failover logic, circuit breakers, local fallbacks, multi-provider routing — these are table stakes. The infrastructure you depend on is going to go down more frequently than historical norms suggest, for reasons that historical norms couldn't anticipate.

Build for it.

Related reading from the CoderOasis library: If you want the CPU-side of this infrastructure story, The CPU-ocalypse Is Here covers how chip shortages compound the capacity problem. For the security angle on AI-generated code flooding platforms, Amazon's Mass Layoffs and Kiro AI is required reading. And if you want to understand why Linus Torvalds is watching his patch queue with increasing suspicion, Linux 7.0 RC6 lays it out.