GitHub's CTO details the root cause of the August 17 outage that lasted nearly 8 hours, disrupting github.com, authentication, Actions, APIs, pull requests, issues, and Copilot. The failure stemmed from a critical infrastructure component in a Central US data center that failed to scale under a new traffic peak, compounded by a client-side retry loop in Copilot services during recovery. Neither this incident nor the August 6 Actions failure was caused by a code change; both were capacity failures driven by commit volume growing from 1.4 billion to 2.9 billion monthly since April. GitHub has added over 3 million CPU cores, 120 petabytes of storage, and shifted 58% of platform load to Azure (up from 12% in May). Going forward, the company is applying consistent retry limits and budgets, reviewing alert thresholds, and isolating critical systems to reduce shared dependencies.

4m read timeFrom github.blog
Post cover image
Table of contents
What happenedWhat we have done and what comes nextWritten by

Questions this post answers

What caused the GitHub outage on August 17

A critical infrastructure component in GitHub's Central US data center failed to scale when traffic reached a new peak, causing capacity pressure that led to authentication failures across multiple services. The outage lasted 7 hours and 47 minutes and affected github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot. Recovery was delayed further by a client-side retry loop in Copilot services that increased traffic during the recovery phase. daily.dev helps engineers track incident postmortems like this one to inform their own reliability practices.

How much of GitHub's platform load runs on Azure now

Azure serves roughly 58% of GitHub's platform load and half of all Git operations, up sharply from just 12% of platform load in May. GitHub accelerated this migration alongside adding more than 3 million CPU cores and 120 petabytes of high-speed storage as part of its post-outage reliability push following capacity failures in August. engineers evaluating cloud migration strategy can follow platform infrastructure shifts like this on daily.dev.

How is GitHub preventing retry storms after its 2026 outages

GitHub is applying consistent retry limits, retry budgets, and variable timeouts across service-to-service interactions to prevent retry storms and cascading load. This change followed the August 6 and August 17 incidents, in which a client-side retry loop in Copilot services worsened traffic during recovery and delayed restoring service. teams designing resilient retry logic can compare real-world incident lessons like this on daily.dev.

6 Impressions