On August 20, 2026, GitHub CTO Vlad Fedorov published an official account of the outage that stuck developers worldwide three days earlier: on August 17, github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot all ran into trouble, and full recovery took 7 hours and 47 minutes. It was GitHub’s second major incident of the month, after an Actions failure on August 6. When a platform this central to the software supply chain goes dark, the explanation matters as much as the fix — and this one is a story about growth outrunning capacity.
Seven Hours and Forty-Seven Minutes: What Broke
During the disruption, the website, sign-in, CI/CD, and the API went down alongside Copilot. Because GitHub sits at the center of global software development, a single failure interrupted deployments, code reviews, and collaboration for countless teams at once — merge queues froze, actions hung mid-run, and AI-assisted workflows lost their backbone. Recovery required rerouting traffic and restoring services in stages, not a single flip of a switch. Copilot was the slowest to come back: client-side retry loops kept amplifying traffic while the service recovered, and GitHub had to mitigate that amplification before it could finish restoring full service. In other words, the recovery was partly throttled by the very users trying to get back on — a dynamic anyone who has run a public API will recognize.
Root Cause: Capacity, Not Code
The report is blunt about cause. This was not triggered by a code or configuration change — a critical infrastructure component in the Central US data center failed to scale when traffic hit a new peak. In GitHub’s own words, the team “failed to scale critical components before demand exceeded their capacity.” The background numbers explain where the pressure came from: since April, monthly commits on GitHub have doubled from 1.4 billion to 2.9 billion. A platform that doubles in four months does not break where engineers expect; it breaks where the traffic curve bends fastest. The most fragile component eventually shows itself, and it picks the moment.
There is an uncomfortable honesty in this kind of postmortem. Code bugs have obvious fixes and regression tests; a capacity shortfall is a bet on a growth curve, and the curve moved faster than the bet. Doubling monthly commits does not just add traffic on existing paths — newer workloads like Copilot and agent-style automation change the shape of traffic itself: more API calls per commit, longer-lived connections, and clients that retry without asking.
GitHub’s Fix List
The remedies fall into three layers. Immediate patches: consistent retry limits, retry budgets, and variable timeouts across service-to-service calls to prevent retry storms, plus a review of lower-priority CPU and memory alerts for components most exposed to spikes. Capacity: more than 3 million additional CPU cores, 120 petabytes of high-speed storage, and expanded network capacity — additions that read like a mid-sized cloud region appearing inside the platform. Architecture: Azure now carries roughly 58 percent of platform load, up from 12 percent in May, spreading risk that used to sit in one place. GitHub is also building read capacity that scales linearly with the number of readers, rolling it out first on its largest monorepos, while isolating critical systems, removing shared dependencies, and investing in testing, safer rollouts, and observability. None of it is glamorous; all of it is the difference between a bad hour and a lost day.
What Teams That Depend on GitHub Should Take Away
Three things are worth carrying home. First, retry strategy is your responsibility: client retries are what slowed Copilot’s recovery, and if your CI pipelines, scripts, or agent workflows lack backoff and hard caps, they become the amplifier next time — hammering a recovering service until it falls over again. Second, plan capacity for peaks, not averages: with monthly commits doubling in four months, any internal estimate of “enough until year end” deserves a recount, and the same logic applies to your own self-hosted infrastructure. Third, critical workflows need a degraded mode — whether your team can keep merging and deploying while authentication or the API is down depends on the fallbacks you build today, not the ones you sketch after an outage report lands in your inbox.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.