When GitHub Went Dark: Inside the 7-Hour Outage That Paralyzed the World's Code

On August 17, 2026, GitHub went dark for nearly eight hours. The outage — lasting 7 hours and 47 minutes — took down github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot. If you tried to ship code that day, you were locked out. And you were not alone: the entire global developer community ground to a halt.

This was not an isolated incident. It was GitHub's second major outage in August alone, following an Actions failure on August 6. The postmortem, published on August 20 by GitHub CTO Vladimir Fedorov, reveals a platform buckling under its own explosive growth — and a company racing to catch up.

What Happened

The root cause was deceptively simple: traffic hit a new all-time peak, and a critical infrastructure component in GitHub's Central US data center failed to scale with it. The capacity pressure cascaded through the system like dominoes. Authentication broke first, and from there, nearly every GitHub service that depends on identity and access followed.

Recovery was not straightforward. Teams had to reroute traffic, isolate the affected infrastructure, and restore services in carefully staged phases. Most of GitHub came back online that day, but Copilot took significantly longer. The reason? A client-side retry loop — when Copilot services started failing, clients kept retrying, generating a feedback loop that amplified traffic during recovery. Engineers had to break that cycle before they could safely restore full traffic.

Not a Code Problem — a Capacity Problem

Here is what makes this outage particularly striking: neither the August 17 outage nor the August 6 incident was caused by a code change or a misconfiguration. There was no bad deploy, no rogue PR, no broken merge. Both were capacity failures at their core. GitHub simply did not scale critical components before demand exceeded their limits.

The numbers tell the story. Since April 2026, monthly commits on GitHub have grown from 1.4 billion to 2.9 billion. That is a 107% increase in roughly four months. GitHub's infrastructure was not designed for that trajectory, and the scaling work that was underway could not keep pace.

The Azure Migration Acceleration

GitHub's response has been to accelerate its migration to Microsoft Azure at a remarkable pace. As of the postmortem, Azure now serves roughly 58% of GitHub's platform load and half of all Git operations — up from just 12% in May 2026. That is a staggering shift in under three months.

The hardware additions are equally impressive:

• Over 3 million CPU cores added
• 120 petabytes of high-speed storage deployed
• Significant network capacity expansions across data centers

They have installed as much hardware as available power allows in existing data centers. The constraint is no longer budget — it is physics. Power, cooling, and physical space are now the limiting factors, which makes the Azure migration not just convenient but essential.

Retry Storms and Cascading Failures

One of the most interesting technical details from the postmortem is the retry loop problem. When Copilot services started failing, client-side retry behavior created a feedback loop — failed requests triggered retries, which increased load, which caused more failures, which triggered more retries. This is a classic distributed systems anti-pattern, and it significantly complicated recovery.

GitHub's response: applying consistent retry limits, retry budgets, and variable timeouts across all service-to-service interactions. This is the kind of systemic change that prevents one component's failure from bringing down the entire platform. They are also reviewing lower-priority CPU and memory alerts to identify components that could fail during sudden traffic spikes — essentially trying to find the next bottleneck before it finds them.

The Bigger Picture: AI Is Eating GitHub

The doubling of monthly commits in four months is not a coincidence. It reflects a fundamental shift in how software is written. AI coding tools — GitHub Copilot, Claude Code, Cursor, and a growing ecosystem of agentic coding assistants — are generating code at an unprecedented scale. When an AI agent can write, test, and iterate on code autonomously, the volume of commits naturally explodes.

This creates a paradox for platform providers. AI tooling drives massive engagement and growth, but it also demands infrastructure that can handle traffic patterns that look nothing like human developer behavior. An AI agent does not take lunch breaks. It does not sleep. It generates commits at 3 AM on a Sunday at the same rate as Tuesday afternoon. Traditional capacity planning, built around human work rhythms, simply does not work anymore.

Lessons for Every Platform Team

GitHub's outage holds lessons that extend far beyond one platform:

• Capacity planning must account for AI-driven growth, not just human-driven growth. The old models of forecasting based on historical human patterns will systematically underestimate demand.
• Retry budgets are not optional. Without bounded retry behavior across all service interactions, a single component failure can cascade into a platform-wide outage through retry storms.
• Migration to cloud infrastructure is not just about convenience — it is about survival. When your growth outpaces your physical data center capacity, the elasticity of cloud is not a luxury. It is a necessity.
• Operational practices must evolve with scale. What works at 1.4 billion monthly commits may catastrophically fail at 2.9 billion. Testing, rollout safety, observability, and alerting all need to scale with the platform.

What Comes Next

GitHub is now working on an architecture that scales read capacity linearly with the number of readers — effectively enabling unlimited read operations. They are rolling it out gradually, starting with the largest monorepos. They are also isolating critical systems and removing shared dependencies between them, reducing the blast radius of future failures.

The company's CTO was direct in his acknowledgment: "The developer community depends on GitHub to build, ship, and operate their work. That is only possible if you can rely on us, and on August 17, you couldn't."

For the millions of developers who lost a day to this outage, that honesty is a start. But trust, as GitHub itself noted, is earned through reliability — not postmortems. The real test will come the next time traffic spikes. Will the 3 million new CPU cores and the Azure migration be enough? Or will we learn, once again, that the world's largest code host is still one capacity failure away from going dark.