Seven Hours and Forty-Seven Minutes, Traced to One Overloaded Proxy

GitHub's own postmortem, published on its engineering blog under the title "The August 17 outage, and the work ahead," traces the failure to an Istio sidecar proxy in its Central US data center that hit its maximum concurrent processing capacity. The autoscaling policy watching over that capacity evaluated only the application service itself, not the connection and concurrency state of the sidecars sitting in front of it, so nothing scaled up when the sidecars maxed out. As those proxies saturated, requests shifted onto other nodes, which then reached their own capacity ceilings in turn, and GitHub's automatic retry logic made the spiral worse by sending fresh requests toward load balancers that were already overloaded. A separate retry bug, reported by The Register as sitting in a VS Code extension used for GitHub Copilot authentication, compounded the failure further: it kept requesting new authentication tokens without pause, pushing GitHub's token-issuance service from a normal baseline of 7,000 to 9,000 requests per second up to 70,000 to 100,000 requests per second, roughly ten times normal load.

The Numbers Behind One Bad Afternoon

The outage ran from 13:28 to 21:15 UTC on August 17, 2026, and GitHub's own status updates put peak error rates at roughly 20 percent for web and API traffic and about 50 percent for archive and raw content downloads, the kind of request a build pipeline or a dependency fetch relies on. Issues, pull requests, APIs, Actions and Copilot were all degraded, along with SAML and OIDC authentication, SCIM, and Team Sync; most services recovered by 16:36 UTC, Actions by 18:03 UTC, and the Copilot token service last, at 21:02 UTC. GitHub was explicit that neither this incident nor the smaller Actions failure on August 6 was caused by a code or configuration change; both, in its own words, were capacity failures at their core, meaning the system ran out of headroom rather than broke from a bug someone shipped.

Outage duration7 hours 47 minutes, 13:28 to 21:15 UTC, August 17, 2026
Peak error rate, web and API trafficabout 20 percent
Peak error rate, archive and raw downloadsabout 50 percent
Monthly commits, April 20261.4 billion
Monthly commits, August 20262.9 billion
GitHub Actions incidents13 in a 17-day span this August, per Tech Times

Commit Volume Nearly Doubled in Four Months

Buried in the same postmortem is the figure that turns this from an outage story into an infrastructure story: GitHub says monthly commit volume has grown from 1.4 billion to 2.9 billion since April 2026, roughly doubling in about four months, alongside charts showing merged pull requests climbing toward 130 million a month and new repositories toward 24 million a month. GitHub had already flagged the driver in its May 2026 availability report, where it acknowledged that AI-assisted coding and agentic workflows were adding strain to its infrastructure, and Microsoft has said publicly that AI now writes as much as 30 percent of the code in some of its own repositories, subject to human review. A platform sized for a world where commits arrive at human typing speed is now absorbing a load pattern set by coding agents that write, branch and push continuously, and GitHub's response so far has been to add capacity: more than 3 million CPU cores and 120 petabytes of high-speed storage, with Azure now carrying roughly 58 percent of platform load, up from 12 percent in May.

GitHub Actions Logged Thirteen Incidents in Seventeen Days

Tech Times, analyzing GitHub's incident history and status data, reported that GitHub Actions alone logged 13 separate incidents in a 17-day span this August, and that its 90-day uptime slipped from 99.39 percent before the August 17 outage to 99.33 percent after, a drop from roughly 13 hours of accumulated downtime in three months to about 14.5 hours. That outlet framed the August 17 incident as having consumed almost an entire year's worth of allowable downtime against a three-nines target on its own. GitHub's own postmortem counts differently, calling August 17 its second significant incident of the month after the August 6 Actions failure, which is a fair count of major platform-wide outages but says nothing about the smaller, more frequent Actions disruptions sitting underneath it. Both counts can be true at once, and together they describe a two-tier reliability problem: the core Git service holds up better than the CI/CD pipeline layered on top of it, and that pipeline is exactly where AI-assisted development puts the most new load.

One Platform, Every Pipeline: The Concentration Risk

For a business that runs its whole engineering workflow through GitHub, meaning source control, CI via Actions, its package registry, and Copilot for code generation, none of that is background noise; it is a single vendor sitting on the critical path of every release. A European development team feels this the same way a US one does during the outage window itself, but carries an extra layer of exposure on top: contractual delivery deadlines, SLA commitments to EU customers, and incident-reporting obligations under frameworks like NIS2 do not pause because the outage originated in a US data center outside the team's control. Treating 'GitHub is down' as background noise stops making sense once the underlying numbers show why it happened: infrastructure built for a slower, human-paced world absorbing a load pattern that has nearly doubled in four months, on a platform that, by its own admission, has spent August fixing the same category of capacity failure twice.

What Redundancy Actually Looks Like

None of this argues for abandoning GitHub, which remains the default for good reasons, but it is a concrete case for treating single-vendor dependency as a planned risk rather than an afterthought discovered mid-outage. That means a mirrored copy of critical repositories on a second host or a self-hosted Git server, an alternate CI runner configuration that can pick up builds when Actions is degraded rather than only when it is fully down, and a local or self-hosted cache for package dependencies so a registry outage does not stop every build in the pipeline. None of these measures need to run continuously; they need to exist, be tested occasionally, and be documented well enough that a team under pressure during the next incident is not improvising a workaround for the first time while the clock on a client deadline keeps running.