Nearly 8 Hours: GitHub Outage Fed by Its Own Retries

GitHub Was Down for Nearly 8 Hours on August 17

GitHub.com suffered a 7-hour-47-minute outage on August 17, 2026, running from 13:28 to 21:15 UTC and degrading nearly every core developer workflow on the platform. Elevated errors and latency hit Issues, Pull Requests, the REST and GraphQL APIs, GitHub Actions, and GitHub Copilot at the same time, so the disruption was not confined to one feature. GitHub's own postmortem, published on github.blog under the title "The August 17 outage and the work ahead," put the peak error rate at around 20% site-wide, and around 50% specifically for archive and raw file downloads. The Register, TechTimes, and dev.to all corroborated the timeline and scope in their own coverage of the incident.

The Cause Was a Proxy Hitting Its Limit, Not a Bad Deploy

GitHub's postmortem states plainly that the outage was not caused by a code or configuration deployment; it was a capacity and monitoring failure inside the company's own network infrastructure. The trigger was an Istio service-mesh sidecar proxy in a Central US data center that hit its concurrency limit once traffic arrived in a new peak pattern the system had not been sized for. A service mesh sidecar sits next to every service instance to manage its network traffic, so when one hits a hard ceiling under unexpected load, everything routed through it starts failing at once rather than degrading gradually.

A Misconfigured Alert Meant Nobody Saw It Coming

An internal monitoring policy was misconfigured and failed to alert GitHub's engineers as the sidecar proxy approached its concurrency ceiling, so the warning that should have triggered a response before users noticed anything simply never fired. That gap matters as much as the concurrency limit itself: a capacity ceiling that is caught early is a quiet capacity upgrade, while one that is caught only after users are seeing errors becomes a multi-hour incident. GitHub has said addressing that monitoring gap is part of the "work ahead" referenced in its postmortem title.

GitHub's Own Retry Logic, Especially From VS Code, Made It Worse

Optimistic client-side retry logic across GitHub's ecosystem turned one overloaded proxy into a platform-wide cascade, and GitHub singled out a retry storm from VS Code clients as a major contributor to how bad the outage got. When a request fails and a client immediately retries without backing off, it does not just fail again, it adds another request to an already-overloaded system, and multiplied across millions of VS Code installations pinging GitHub in the background, that pattern turned a contained proxy problem into a platform-wide one. This is the detail that turns the incident from a story about GitHub's infrastructure into a story about how any client of any API should be built.

For Any Business Running Its Pipeline Through GitHub, This Was an 8-Hour Blackout

Most businesses think of a GitHub outage as a developer inconvenience, something engineers grumble about while they wait, but for any company that has quietly made GitHub Actions and Copilot part of its release pipeline, 7 hours 47 minutes without GitHub is 7 hours 47 minutes in which you cannot ship a hotfix, cannot merge a security patch, and, if Copilot is part of the workflow, lose an AI-assisted coding tool mid-task. That is a single-vendor concentration risk hiding inside what looks like "just using GitHub," and it does not show up on a budget line the way a software subscription does. The sharper lesson is the retry storm: if GitHub's own client software made an outage worse by retrying aggressively without backoff, any business building its own systems against third-party APIs should be auditing its own retry logic for the same failure mode internally, not filing this away as purely GitHub's problem.

Read next: Wiz's AI Agent Hacked Snowflake, Then Blamed Copilot  |  Your Second Git Host Turned Itself On By Default