GitHub revealed that the outage affecting its platform on August 17 and lasting 7 hours and 47 minutes resulted from a critical infrastructure component failing to scale as traffic reached record levels inside its data center in the central United States region. The resulting capacity pressure spread problems across several systems, affecting github.com, authentication, GitHub Actions, APIs, pull requests and issues, as well as Copilot, while the outage’s impact extended to developers and organizations around the world.
The incident represents the second major event GitHub faced during August, following a failure that affected Actions on August 6. The company explained that the investigation found no connection between either incident and a code or configuration change; rather, both centered on insufficient capacity, as essential components were not expanded before demand exceeded their capacity. According to GitHub, the number of monthly commits rose from 1.4 billion in April to 2.9 billion since then, but the company acknowledged that usage growth does not exempt it from responsibility for preventing outages.
How did the services recover?
The recovery process required redirecting traffic, isolating the affected infrastructure, and restoring services in stages. Most GitHub services resumed operation the same day, but some Copilot services took longer. Errors in those services caused a client-side retry loop that increased traffic during recovery, forcing teams to limit this behavior before safely redirecting traffic.
GitHub says the full root-cause analysis report includes a detailed technical timeline, while the company continues implementing commitments it previously announced to improve availability and reliability.
What is changing in practice?
GitHub’s plan focuses on increasing capacity, improving efficiency, and removing architectural bottlenecks. The company announced that it had added more than 3 million CPU cores and 120 petabytes of high-speed storage, along with additional network capacity. It also installed as much hardware as possible within the available power at its existing data centers, while accelerating its transition to Azure.
Azure currently handles about 58% of the GitHub platform’s workload and half of Git operations, compared with 12% of the platform’s workload in May. This expansion has also helped support growth in GitHub Actions task executions. The company is working on a new architecture to scale read capacity in massive repositories linearly with the number of readers, theoretically enabling unlimited read operations, with a gradual rollout set to begin in the largest monolithic repositories.
Reducing the blast radius and preventing storms
GitHub does not view scaling alone as sufficient; it has assigned additional teams and resources to availability and invested in stronger testing, safer deployment processes, better monitoring, and more effective alerts. It is also isolating critical systems and removing shared dependencies between them to reduce the likelihood of an outage and limit its impact if one occurs.
Based on the August 6 and 17 incidents, the company will apply unified retry limits and budgets, along with variable timeouts for communication between services, to prevent retry storms and cascading loads. It is also reviewing lower-priority CPU and memory alerts to detect components that could fail during sudden traffic spikes. These measures are directly important to developers and organizations that rely on GitHub to build, ship, and operate software, since platform recovery depends not only on restoring service but also on preventing a recurrence and containing the outage’s scope when one occurs.