Code-hosting giant GitHub has published a blog post explaining exactly what happened during an outage that lasted seven hours and 47 minutes earlier this week. The outage which took place on Monday, August 17, was traced to a critical infrastructure component housed in one of its data centres in the US.
The component failed to scale when traffic reached a new peak resulting in capacity pressure which spread through GitHub’s systems, causing authentication failures and disrupting multiple GitHub services, the Microsoft-owned platform said.
The outage disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, potentially affecting thousands of developers and organisations around the world.
While most GitHub services recovered earlier that day, some Copilot services took longer. As part of its recovery efforts, GitHub said that it initiated several coordinated actions such as re-routing Teams traffic, isolating affected infrastructure, and restoring services in stages.
The platform also ruled out code or configuration changes as the root cause of the outage. Both incidents were capacity failures at their core, GitHub said.
“We failed to scale critical components before demand exceeded their capacity. Since April, monthly commits have grown from 1.4 billion to 2.9 billion. That growth explains the pressure on our systems, but it does not excuse these outages,” it added.
GitHub has suffered two major outage incidents in the month of August alone. On August 6, a configuration change inadvertently reduced the capacity of the service that processes GitHub Pages deployments. This resulted in users experiencing delays when starting tasks using Copilot Cloud Agent and not being able to see the status of these tasks.
In response to the August 6 and August 17 incidents, GitHub said that it is applying consistent retry limits, retry budgets, and variable timeouts across service-to-service interactions to prevent retry storms and cascading load. Additionally, it is also reviewing lower-priority CPU and memory alerts to identify components that could fail during sudden traffic spikes.
While these are immediate fixes, GitHub has also outlined its long-term plan to prevent similar outages. The company outlined the following three key priorities:
-Adding capacity -Improving efficiency -Removing architectural bottlenecks
Furthermore, GitHub said it has added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity while accelerating its migration to Microsoft Azure.
Currently, Azure serves roughly 58 per cent of GitHub’s platform load and half of all Git operations, up from 12 per cent of platform load in May 2026. “Our next milestone is an architecture that scales read capacity linearly with the number of readers, enabling unlimited read operations. We will roll it out gradually, beginning with the largest monorepos,” the company said.
“In addition, we are also isolating critical systems and removing shared dependencies between them. This work is designed to reduce the likelihood of an outage and limit its impact when one occurs,” it added.
