GitHub said an August 17 service outage that lasted 7 hours and 47 minutes was caused by capacity limits in its infrastructure, outlining a reliability plan after a second significant incident in the same month.
The company described the disruption as a global incident affecting developers and organizations that rely on GitHub to build and ship software. According to GitHub, the outage affected github.com, authentication, GitHub Actions, APIs, pull requests, issues and Copilot. The company said an earlier August 6 incident had involved an Actions failure, making the August 17 event part of a wider reliability problem it is now trying to address more quickly.
GitHub attributed the August 17 outage to a new traffic peak and a critical infrastructure component in its Central US data center that did not scale sufficiently. The company said pressure from that failure moved across systems, contributing to authentication problems and disruption across multiple services. It said its investigation found that neither the August 6 nor August 17 incidents was triggered by a code or configuration change, describing both as capacity failures.
Restoring service required teams to take several coordinated steps, GitHub said. Those steps included rerouting traffic, isolating affected infrastructure and bringing services back in phases. The company said most services recovered earlier on August 17, while some Copilot services took longer because errors in those systems caused a client-side retry loop that added traffic during recovery. GitHub said it had to mitigate that behavior before traffic could be safely restored.
The company linked the strain on its systems to sharp growth in usage. It said monthly commits rose from 1.4 billion in April to 2.9 billion, a level of demand that increased pressure on the platform but, in GitHub’s account, did not excuse the outages. GitHub said its reliability work is focused on adding capacity, improving efficiency and removing architectural bottlenecks.
As part of that program, GitHub said it has added more than 3 million CPU cores, 120 petabytes of high-speed storage and additional network capacity. It said it installed as much hardware as existing data center power limits allowed while accelerating migration to Azure. GitHub said Azure now serves roughly 58% of GitHub’s platform load and half of all Git operations, compared with 12% of platform load in May.
The company also said it is working on an architecture intended to scale read capacity in line with the number of readers, starting with the largest monorepos. Operational changes are also planned or underway, including stronger testing, safer rollouts, improved observability and alerting, and greater isolation of critical systems to reduce shared dependencies.
GitHub said the August incidents prompted two immediate changes: broader use of retry limits, retry budgets and variable timeouts to reduce cascading traffic, and a review of lower-priority CPU and memory alerts to find components that could fail during sudden spikes.
