Summary: GitHub’s postmortem says the August 17 outage disrupted github.com, authentication, Actions, APIs, pull requests, issues, and Copilot for 7 hours and 47 minutes. The cause was a critical Central US infrastructure component that failed to scale before demand exceeded capacity, not a code or configuration bug. Remedies include retry limits, more than 3 million additional CPU cores, and shifting more load to Azure.
An official account of the outage appeared on August 20, 2026, from GitHub CTO Vlad Fedorov — three days after the event that left developers worldwide stuck. Trouble arrived on August 17 across github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot simultaneously, and it took 7 hours and 47 minutes to reach full recovery. That made it the month’s second major incident for GitHub, after an Actions failure on August 6. A platform sitting this deep in the software supply chain going dark deserves as clear an explanation as the repair itself, and the explanation here concerns growth that outran capacity.
What Happened in Those Seven Hours and Forty-Seven Minutes
The disruption pulled down the website, sign-in, CI/CD, and the API, with Copilot caught as well. GitHub is where global software development happens, so one failure halts deployment, code review, and day-to-day teamwork for countless teams at the same moment: merge queues stopped moving, actions sat mid-run, and AI-assisted workflows were left without their backbone. Recovery was not a matter of one switch — traffic had to be rerouted, then services brought back a stage at a time. Copilot came back last of all. While the service was still recovering, retry loops on the client side kept pushing traffic higher, and GitHub had to bring that amplification down before it could complete the restoration. In effect, the users hurrying to reconnect were part of what slowed the return — a pattern familiar to anyone who has operated a public API.
The Cause Was Capacity, Not Code
The report does not soften the cause. Nothing in the code or the configuration set this off; what failed was one critical infrastructure component in the Central US data center, which could not scale as traffic reached a new peak. GitHub’s own wording: the team “failed to scale critical components before demand exceeded their capacity.” The pressure behind it shows up in the numbers — since April, monthly commits have gone from 1.4 billion to 2.9 billion, a doubling in four months. A platform growing at that rate rarely breaks where engineers would point; it breaks at the spot where the traffic curve bends hardest. Sooner or later the weakest component announces itself, and its timing is never good.
Postmortems like this one carry an honesty that is hard to sit with. A code bug comes with a fix and a regression test; capacity falling short is a wager on how fast you will grow, and the growth outran the wager. When monthly commits double, the added load does not stay on the paths that already existed. Workloads such as Copilot and agent-style automation reshape traffic itself: each commit now drags more API calls behind it, connections stay open longer, and clients retry on their own initiative.
The Fix List GitHub Has Laid Out
Three layers of remedy appear in the report. First, patch the immediate danger: put consistent retry limits, retry budgets, and variable timeouts in place across every service-to-service call so retry storms cannot form, and take a second look at the lower-priority CPU and memory alerts on the components spikes reach first. Second, add capacity: over 3 million CPU cores, 120 petabytes of high-speed storage, and wider network bandwidth — an expansion on the order of a mid-sized cloud region sprouting inside the platform. Third, change the architecture: around 58 percent of platform load now runs on Azure, against 12 percent in May, which spreads risk that used to sit in one place. Read capacity that expands linearly with the number of readers is also under construction, starting with the largest monorepos, while critical systems are isolated, shared dependencies removed, and testing, safer rollouts, and observability given more investment. None of it is glamorous; all of it separates a bad hour from a lost day.
Takeaways for Teams That Depend on GitHub
Three things are worth taking home. First: retrying is your call to get right. Client retries are what stretched Copilot’s recovery, so a CI pipeline, a script, or an agent workflow with no backoff and no hard cap becomes the amplifier next time, hammering a service that is still recovering until it falls over again. Second: size for peaks, not averages. Four months of doubling monthly commits means an internal “enough until year end” deserves a recount, and infrastructure you host yourself follows the same logic. Third: critical workflows need a degraded mode. Whether a team can keep merging and deploying while authentication or the API is down comes down to the fallbacks built today, not the ones sketched once an outage report lands in your inbox.