GitHub's CTO on a 7 hour 47 minute outage: "we let you down"

GitHub was down for most of a working day and took Copilot with it. Four days later its CTO published the sentence engineers wanted to read.

What happened on August 17

The platform served elevated errors from 13:28 to 21:15 UTC, 7 hours and 47 minutes, across Issues, Pull Requests, the API, Actions and Copilot.

Web and API error rates peaked near 20 percent. Raw content downloads peaked near 50 percent. Copilot authentication kept failing after other services had recovered.

On August 21 the company published its account. CTO Vladimir Fedorov wrote: “If you were trying to ship software that day, we let you down.”

The cause was growth, not a bad deploy

Neither incident came from a code or configuration change, which is the usual suspect. The platform simply failed to scale with demand, and autoscaling problems plus a retry storm from VS Code clients made it worse.

The growth figure explains the pressure. GitHub now handles about 2.9 billion commits a month, up from 1.4 billion in April.

Why outages amplify now

The retry storm is the part that generalizes. Coding agents and IDE clients do not wait politely when a request fails, they retry, so every failure gets multiplied by the tooling built on top of the platform. An outage that would once have meant idle developers now means an automated load test running against a system already in trouble.

GitHub says it will rearchitect for linear read scaling, isolate critical systems and tighten retry limits. Until that ships, a single provider carrying source control, CI and the coding assistant remains one dependency and one failure domain.