GitHub says capacity failures caused its second August outage

On August 17, GitHub experienced an outage lasting 7 hours and 47 minutes. It disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, affecting developers and organizations around the world; anyone trying to ship software that day was blocked. It was GitHub's second significant incident in August, after an Actions failure on August 6.

According to GitHub, the outage began when traffic reached a new peak and a critical infrastructure component in the company's Central US data center failed to scale with it; GitHub does not name the specific component. The resulting capacity pressure spread through GitHub's systems, causing authentication failures and disrupting the services listed above. Recovery took several coordinated steps: teams rerouted traffic, isolated the affected infrastructure, and restored services in stages. Most services came back earlier in the day, but some Copilot services took longer, because errors in those services triggered a client-side retry loop that increased traffic during the recovery itself; GitHub had to mitigate that retry behavior before it could safely restore traffic.

GitHub is explicit that neither the August 6 nor the August 17 incident was caused by a code or configuration change: both, it says, were capacity failures at their core, meaning its infrastructure did not scale fast enough for demand. The company frames its own growth as context, not excuse: since April, its monthly commit volume has more than doubled, from 1.4 billion to 2.9 billion. GitHub says that growth explains the pressure on its systems but does not excuse the outages, and that the two incidents show it must accelerate reliability work it had already described earlier in the year.

As part of reliability commitments made earlier this year, GitHub says it has focused on three priorities: adding capacity, improving efficiency, and removing architectural bottlenecks. Concretely, it has added more than 3 million CPU cores, 120 petabytes of high-speed storage, and additional network capacity, installing as much hardware as available power allowed in its existing data centers while accelerating its migration to Azure. Azure now serves roughly 58% of GitHub's platform load and half of all Git operations, up from 12% of platform load in May. GitHub says Azure's added infrastructure and capacity have also sped up its work to scale the largest monorepos; its next milestone is an architecture that scales read capacity linearly with the number of readers, enabling unlimited read operations, which it plans to roll out gradually, starting with the largest monorepos.

GitHub also says its operational practices had not kept pace with the speed and complexity of change, so it has redirected teams and resources toward availability and invested in stronger testing, safer rollouts, better observability, and more effective alerting; it is additionally isolating critical systems and removing shared dependencies between them, work designed to reduce the likelihood of an outage and limit its impact when one occurs, rather than eliminate outages outright. The August 6 and 17 incidents specifically led to two immediate changes: consistent retry limits, retry budgets, and variable timeouts across service-to-service interactions, to prevent retry storms and cascading load of the kind that prolonged the Copilot recovery; and a review of lower-priority CPU and memory alerts, to identify components that could fail during sudden traffic spikes.

Key facts

GitHub's August 17 outage lasted 7 hours and 47 minutes and disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot.
It was GitHub's second significant incident in August, after an Actions failure on August 6; GitHub says neither was caused by a code or configuration change, and both were capacity failures.
A critical infrastructure component in GitHub's Central US data center failed to scale as traffic hit a new peak; recovery of Copilot services was further slowed by a client-side retry loop that GitHub had to mitigate before restoring traffic.
Since April, GitHub's monthly commit volume has more than doubled, from 1.4 billion to 2.9 billion, growth GitHub says explains the pressure on its systems but does not excuse the outages.
GitHub has added more than 3 million CPU cores and 120 petabytes of storage and shifted more load to Azure, which now handles roughly 58% of platform load and half of all Git operations, up from 12% in May; it is also adding consistent retry limits across services and rolling out a new linearly-scaling read architecture, starting with its largest monorepos.

Why it matters

This is GitHub's second major outage within the same month, and the company is unusually direct that neither was a software bug: both were capacity failures, meaning growth in demand outran the infrastructure's ability to scale. GitHub had already described reliability work underway in posts from March and April; it says these two August incidents make clear that work must accelerate. The scale context it gives is stark: monthly commit volume has more than doubled since April, from 1.4 billion to 2.9 billion, which GitHub says explains the pressure on its systems even as it insists that explanation does not excuse the outages. For a platform whose core value is being available whenever developers need to build, review, or ship code, two capacity-driven failures in one month signals that its growth curve and its infrastructure curve have not been moving together.

Who it affects

Anyone using github.com, GitHub authentication, GitHub Actions, the GitHub API, pull requests, issues, or Copilot was affected during the 7 hour 47 minute window, and GitHub says explicitly that developers and organizations trying to ship software that day were let down. More broadly, any team whose build, review, or deployment pipeline depends on GitHub's uptime is exposed if the same capacity gap resurfaces, since this is the second such incident in the same month; teams running the very largest monorepos are also the ones who will see GitHub's planned read-scaling architecture roll out first, since that is where it is starting.

How to use it

There is no product change here for a developer to adopt directly, but the post describes changes to how GitHub's own infrastructure will behave under stress. Consistent retry limits, retry budgets, and variable timeouts are being applied across service-to-service interactions specifically to stop the kind of client-side retry storm that prolonged the Copilot portion of this outage, so services calling into GitHub may now run into server-side limits rather than the outage-time symptom recurring. Teams operating the largest monorepos are positioned to be first in line for the new linearly-scaling read architecture as it rolls out gradually. GitHub is also reviewing lower-priority CPU and memory alerts to catch components that could fail during sudden traffic spikes before they cause an outage.

How solid is it

This is GitHub's own account, published as company news on its blog. The post is written in the first person, for example describing reliability work "I shared" in March and April, and is immediately followed by a biography of Vladimir Fedorov, GitHub's Chief Technology Officer; GitHub attaches no explicit byline, but the placement points to him as the account's author. Fedorov's background, per that biography, includes 12 years at Facebook, now Meta, as a senior vice president leading engineering teams of more than 2,000 people across privacy, ads, and platform, and co-founding the data-governance startup UserClouds before joining GitHub. Every figure in the post, the outage duration, the commit growth, the CPU and storage additions, and the Azure percentages, is self-reported by GitHub, with no independent confirmation in this text; the post references a fuller "root cause analysis" and a "detailed technical timeline" as existing elsewhere but does not reproduce them here.

Risks and caveats

GitHub does not name the specific infrastructure component that failed to scale in its Central US data center, nor does it state a year for the August 17 outage, the August 6 incident, or the commit growth measured since April. No customer compensation, SLA credits, or refunds are mentioned anywhere in the post. GitHub itself frames its work isolating critical systems as designed to reduce the likelihood of an outage and limit its impact when one occurs, not to eliminate outages, which is itself an acknowledgment that a further incident remains possible; two capacity failures in the same month suggest the gap between GitHub's growth and its infrastructure may not be fully closed yet.

“If you were trying to ship software that day, we let you down.”

— GitHub