What happened on August 17
GitHub suffered a 7-hour and 47-minute outage on August 17 that took down github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot for developers worldwide. This followed an earlier GitHub Actions failure on August 6, marking the second significant incident in the month.
The root cause was a capacity failure. A new traffic peak hit the Central US data center, and a critical infrastructure component failed to scale to meet it. The resulting capacity pressure cascaded through the systems, producing authentication failures and disrupting multiple services. Recovery required coordinated traffic rerouting, isolation of affected infrastructure, and staged restoration of services.
Most services came back earlier that day, but some Copilot services lagged behind. Errors in those services triggered a client-side retry loop that drove up traffic during recovery. Teams had to mitigate that behavior before safe restoration could proceed.
Notably, neither this outage nor the August 6 incident was caused by a code or configuration change. Both were capacity failures. Monthly commits have doubled since April, from 1.4 billion to 2.9 billion. Growth explains the pressure but does not excuse the outages.
Capacity work underway
Following reliability commitments made earlier this year, GitHub has focused on three fronts: adding capacity, improving efficiency, and addressing architectural bottlenecks. In concrete terms, this has meant more than 3 million CPU cores, 120 petabytes of high-speed storage, and substantial network capacity. Hardware has been installed up to the power limits of existing data centers while migration to Azure proceeds.
Azure now serves roughly 58% of GitHub's platform load and half of all Git operations, up from 12% in May. This expanded footprint has kept pace with growth in GitHub Actions job runs.
Azure infrastructure has also accelerated work on scaling the largest monorepos. The next milestone is an architecture that scales read capacity linearly with reader count, enabling unlimited reads. That rollout will begin gradually, starting with the largest monorepos.
Operational changes and hardening
Scale is not the only obstacle. The increasing pace and complexity of change have outpaced existing operational practices. Teams have been redirected toward availability, with investments in stronger testing, safer rollout procedures, better observability, and more effective alerting. Progress is real but incomplete.
GitHub is also isolating critical systems to eliminate shared dependencies between them. The goal is twofold: reduce the probability of an outage and limit blast radius when one does occur.
Both August incidents produced immediate follow-up work. First, consistent retry limits, retry budgets, and variable timeouts are being applied across service-to-service interactions to prevent retry storms and cascading load—the retry loop seen during Copilot recovery being a case in point. Second, lower-priority CPU and memory alerts are being reviewed to identify components that might fail under sudden traffic spikes.
The reliability of the platform is the basis of the developer community's ability to build and ship software. August 17 exposed a gap in that reliability. Closing it depends on sustained work across scaling, architecture, and operational discipline—which is where the effort now goes.
