GitHub's postmortem: commit volume doubled in four months

We covered the August 17 GitHub outage before the cause was public. It's public now, and the interesting part isn't the failure — it's the load curve underneath it. GitHub CTO Vlad Fedorov published the postmortem on August 20: monthly commits went from 1.4 billion in April to 2.9 billion in August. Four months, roughly double. A capacity component didn't scale in time, and the platform every one of your builds depends on fell over for 7 hours and 47 minutes.

What actually happened

Per GitHub's own writeup, this was not a bad deploy or a config change. A critical infrastructure component in the Central US data center failed to scale as traffic hit levels it hadn't seen, capacity pressure cascaded into authentication, and authentication took everything else with it — Actions, API, pull requests, issues, Copilot, SSO.

The numbers Fedorov put next to it explain why the ceiling moved. Around 130 million pull requests merged per month. Roughly 24 million new repositories per month. GitHub Actions at 115.4 million completed runs. And the in-flight Azure migration went from 12% of platform load in May to 58% in August — meaning the capacity story and the migration story are the same story.

GitHub says it has already added more than 3 million CPU cores and 120 petabytes of storage, and commits to isolating critical systems, consistent retry limits and budgets to stop cascades, safer rollouts, and a review of low-priority alerts that flag components fragile under spikes.

Why doubling commit volume matters for your business

The retry budget line is the one to copy. GitHub's own fix list includes "consistent retry limits and budgets to prevent cascading failures." That's the lesson for your stack, not theirs. When your CI can't reach a registry, an unbounded retry loop converts one upstream hiccup into a self-inflicted denial of service against a service that's already struggling. Cap retries, add jitter, fail the job fast, and let a human decide whether to re-run.

Your agents are part of that curve. Commit volume doubling in four months is not developers typing faster. If you're running coding agents, you are generating pushes, Actions runs, and API calls at a rate your pipeline was never sized for — and the bill and the queue depth are yours. Meter your agents' CI consumption the same way you'd meter their tokens.

Authentication is the real single point of failure. The outage spread because auth was in the cascade path. Check what in your business breaks if your identity provider is unreachable for eight hours: deploys, admin panels, customer logins, support tooling. Then decide which of those genuinely need to be independent of it.

Plan for a full working day, not a blip. Nearly eight hours means one incident can eat an entire annual downtime budget. That doesn't call for leaving GitHub. It calls for a mirrored registry, vendored critical dependencies, and one deploy path that doesn't route through a single upstream. It's a day of work, and it converts an outage from an outage into an inconvenience.

Sources: The GitHub Blog, The Register.