Share with your CTO
GitHub logged five availability incidents in August 2026, and the pattern is harder to dismiss than any single outage. Capacity limits, not software bugs, drove most of the failures: a pod shortage cascaded into nine hours of Actions and Copilot downtime on August 6, a traffic spike pushed load balancer limits past their ceiling on August 17 with a 56% peak front-door failure rate hitting roughly 29,000 organizations, and a database saturation event on August 26 prompted GitHub to admit directly that shared infrastructure has not kept up with month-over-month Actions growth. GitHub is investing in remediation, including migrating MySQL primaries to Azure and rerouting a third of Actions jobs to spare capacity, but the investments trail the demand curve.
What this means for your business
GitHub has quietly crossed from code host to delivery infrastructure. When Actions goes down, builds stop. When Copilot’s agent loses status visibility, engineers don’t know which tasks finished and which silently failed. That’s not a vendor inconvenience. That’s a production incident your on-call team inherits, even though the root cause is three layers upstream in a platform you don’t operate.
The retry storm on August 17 is the detail worth studying. A latent client-side retry bug amplified traffic to a single internal authentication endpoint and turned a degraded state into a near-total failure. The same dynamic plays out inside customer environments all the time: your team’s retry logic, written to be polite under normal conditions, becomes an attack on an already-struggling upstream. Any engineering organization that has grown dependent on GitHub’s APIs without auditing its own retry and backoff behavior is carrying undisclosed blast-radius risk.
The signal worth watching: GitHub is also now partially dependent on upstream model providers it doesn’t control. The August 27 incident hit 63% of Copilot requests routed to the Kimi K3 model while other models ran fine. As Copilot routes work across multiple model backends, GitHub’s reliability ceiling is increasingly set by the weakest provider in that mix on any given day. The question for your platform team is whether your deployment and review workflows can degrade gracefully when one piece of that stack drops, or whether they collapse entirely.
Concept deep-dive: Retry storm
A retry storm happens when clients, designed to automatically retry failed requests, all hammer a struggling service simultaneously instead of backing off. It exists because individual retry logic is sensible in isolation: if a request fails, try again. But under a partial outage, thousands of clients retrying in tight loops can multiply traffic to a broken endpoint by an order of magnitude, turning a degraded service into a complete one. Think of it as a traffic jam where every driver, frustrated by the slowdown, makes a U-turn and takes the same alternate route. For engineering teams, the business consequence is that your own code can deepen an outage you didn’t cause.
Based on reporting from GitHub’s August Outages Show Growth Is Outpacing Infrastructure, originally published 2026-09-11 04:45:00.
