GitHub's Seven-Hour Outage: Capacity Failed to Keep Up With a Doubling of Commits

GitHub experienced an extended outage on Monday, August 17, 2026, leaving several of its services inaccessible for more than seven hours. In a post-mortem published August 20 and authored by Vlad Fedorov, GitHub attributed the incident to capacity issues rather than a code or configuration change (GitHub Blog).

Traffic on the platform reached a new peak, and a critical infrastructure component in GitHub's Central US data center failed to scale with it (Engadget). The same Engadget report, published August 20, notes that GitHub's monthly commits grew from 1.4 billion to 2.9 billion between April and August 2026, more than doubling in four months. A commit is a saved change to a codebase, and GitHub tracks billions of them every month as developers push updates.

GitHub stated that the commit growth explains the pressure on its systems but does not excuse the outages (Engadget). The company is now reviewing CPU and memory alerts to identify server components that might fail during high-traffic periods. It is also applying consistent retry limits, retry budgets, and variable timeouts across service-to-service interactions to prevent retry storms and cascading load (Engadget).

A retry storm happens when one service slows down or stops responding, causing other services that depend on it to automatically resend their requests. Those repeated requests pile up, multiplying the load on the already-struggling service and spreading the failure further. Retry budgets and variable timeouts are standard techniques that cap how many times a service will retry and how long it will wait before giving up, so a single slowdown does not cascade into a platform-wide outage.

The August 17 incident is the latest in a series of availability challenges GitHub has faced as its platform scales. In April 2026, GitHub reported that a cluster became overloaded, likely due to a botnet attack, and stopped returning search results, though with no data loss (GitHub Blog). That same April update noted that GitHub had begun executing a plan in October 2025 to increase capacity by 10X, with the goal of substantially improving reliability and availability. GitHub's May 2026 availability report, published June 11, stated that the company had more than doubled its effective capacity in four months but still experienced nine incidents resulting in degraded performance that month (GitHub Blog).

The growth trajectory is steep by any measure. As of June 2026, GitHub's monthly commits had already nearly doubled year over year, crossing 1.4 billion per month, with over 2 billion GitHub Actions minutes run per week (GitHub Blog). GitHub Actions is the platform's built-in automation system, which runs workflows like testing, building, and deploying code without human intervention. By August, that monthly commit figure had reached 2.9 billion. The platform is absorbing in months what previously took years of organic growth, and the infrastructure is straining under the acceleration.

Several factors are likely converging to drive this volume. The rapid adoption of AI-assisted development tools, which generate code at machine speed, and the proliferation of automated CI/CD pipelines running on GitHub Actions, both contribute to commit volume in ways that scale differently from human-driven development. CI/CD, short for continuous integration and continuous deployment, is the practice of automatically testing and releasing code every time a developer saves a change. The 2 billion weekly Actions minutes figure suggests that automated workflows, not just developer push activity, are placing substantial load on the platform's infrastructure.

The specific failure mode GitHub described, a critical component unable to scale with a traffic peak, is a classic capacity-bound bottleneck. The remediation steps target the secondary effects of such failures: when a downstream service becomes slow or unresponsive, upstream services retry requests, multiplying load and creating cascading failures that spread far beyond the original point of failure. These are well-understood patterns in distributed systems engineering, and the fact that GitHub is applying them now suggests they were not uniformly in place across all service-to-service interactions prior to the incident.

The broader context here is the gap between GitHub's capacity expansion efforts and the rate of demand growth. The company more than doubled effective capacity in four months, yet commits doubled in the same window. A 10X capacity plan initiated in October 2025 is still underway. The math suggests that even aggressive infrastructure investment is struggling to keep pace with the demand curve, and that each layer of capacity added is consumed faster than the last.

GitHub's candor in stating that growth explains but does not excuse the outage is worth noting. The company is framing this as an engineering problem to solve, not an unavoidable external event, which is the right posture for a platform that has become critical infrastructure for the global software industry. The concrete remediation steps, while standard, address real failure modes. The open question is whether they will be sufficient against a growth rate that shows no sign of plateauing.