GitHub published a postmortem this week for its August 17 outage — the second major one that month — and buried in the “work ahead” section is a number that should make every tech lead running a fleet of coding agents stop and do some arithmetic: GitHub now processes 2.9 billion commits, 130 million merged pull requests, and 24 million new repos per month, and AI coding agents alone are generating roughly 17 million pull requests a month. Back in April, GitHub was already straining at 1.4 billion commits/month. That’s a doubling of commit volume in four months. Nothing about traditional capacity planning assumes a growth curve like that, because nothing about traditional capacity planning was built for a world where the primary git client isn’t a human typing git push a dozen times a day.

The math that breaks autoscaling assumptions

Standard autoscaling logic — add capacity proportional to observed load, with headroom for normal traffic spikes — assumes load grows roughly linearly with your user count, or at worst follows predictable seasonal patterns (Black Friday, product launch day). GitHub’s own explanation for the outage was a “capacity shortage” where usage growth outpaced auto-scaling. The reason that’s worth sitting with isn’t that GitHub’s engineers are bad at capacity planning — it’s that a fleet of autonomous agents doesn’t behave like a fleet of humans, even at the same headcount.

One human developer working on a feature does roughly this per day: a handful of commits, one or two pushes, one PR open, maybe a rebase. A single agentic coding session doing the same feature can look completely different: clone or fetch on every fresh container spin-up, a commit per iteration of a test-fix loop, a force-push on every retry, a PR opened per candidate branch if you’re running an “generate N candidates, pick the best” pattern, and a webhook fired on every single one of those events. If your team runs five engineers each backed by two or three parallel coding agents — which is an entirely normal Claude Code / Codex / Cursor setup in mid-2026 — you can be generating an order of magnitude more git operations than your headcount would suggest, without anyone consciously deciding to “scale up load on GitHub.”

The Azure dependency detail that’s easy to miss

Buried in the same postmortem: Microsoft Azure now handles roughly 58% of GitHub’s platform load and half of all Git operations. That’s not a criticism of the architecture — Azure is a reasonable substrate for GitHub to run on — but it’s a useful data point for anyone doing failure-domain analysis on their own CI/CD pipeline. If your deploy pipeline, your git hosting, and your compute for running agents all ultimately share a failure domain (even indirectly, through a shared cloud provider having a bad day), an outage isn’t independent across those three things the way your incident runbook probably assumes. Worth an actual audit: when GitHub goes down, does your CI also degrade because it’s colocated in the same region as your agent runners? Does your on-call rotation have a fallback that doesn’t also depend on GitHub Issues to coordinate the incident?

A rough cost model for your own agent fleet

Before reading this postmortem I hadn’t actually sat down and estimated what my own agent-driven git traffic looks like versus a human-paced baseline. Rough version, worth running for your own team:

human_dev_git_ops_per_day  = commits(~6) + pushes(~3) + prs(~1) + fetches(~10)
agent_session_git_ops      = clone_or_fetch(1 per container spin-up)
                            + commits(1 per test-fix iteration, often 5-15)
                            + force_pushes(1 per retry, often 3-8)
                            + prs(1 per candidate branch, 1-5 if fan-out pattern)
                            + webhook_events(1 per above operation)

agents_per_dev              = 2-3  # typical parallel subagent / worktree setup
multiplier                  = (agent_session_git_ops * agents_per_dev) / human_dev_git_ops_per_day

Plug in conservative numbers — 8 commits per agent session, 2 force-pushes, 2 PRs per fan-out, 3 agents running in parallel per engineer — and you land somewhere around a 6-10x multiplier on raw git operation volume per engineer, before counting webhook fan-out to CI, status checks, and any bot that re-fetches on every push. That roughly tracks with GitHub’s own doubling-in-four-months trajectory, and it’s the kind of number that should show up in your own infra capacity conversations, not just GitHub’s.

What I’ve actually changed because of this

A few concrete adjustments worth making if you’re running a real agent fleet against shared git infrastructure, your own or a vendor’s:

1. Stagger scheduled agent runs. If your nightly digest tasks, batch refactors, or scheduled agent jobs all fire at the same cron minute, you’re creating exactly the synchronized-burst pattern that breaks autoscaling assumptions. Jitter your cron schedules.
2. Cap fan-out width explicitly. “Generate 5 candidate branches and pick the best” is a real pattern, but it’s also a 5x multiplier on PR and webhook volume for a single logical unit of work. Default to fewer candidates unless you have a specific reason to widen.
3. Prefer fetch-and-rebase over repeated force-push-on-retry where your workflow allows it — every force-push is a full ref update and a webhook event; batching retries into a single push at the end of a session cuts operation count meaningfully.
4. Audit your failure domains, not just your uptime SLA. Know what actually shares infrastructure with your git host before you need that answer during an incident, not while writing the postmortem.

The bigger lesson isn’t really about GitHub specifically — it’s that the assumption baked into most infrastructure, including infrastructure you don’t control, is still “load scales with human headcount.” That assumption quietly stopped being true sometime in the last year, and the organizations that notice before their vendor’s postmortem tells them are the ones that don’t get paged for someone else’s capacity shortfall.