GitHub reports 7 hours and 47 minutes of disruption on August 17, with different services recovering at different times. Its technical account connects a sidecar concurrency limit, cascading load-balancer saturation and a client retry loop.
The bottleneck was outside the watched container
The official incident report identifies an Istio sidecar reaching concurrency limits while the scaling policy watched the host service instead. Four HAProxy nodes then exhausted their flow limits, impairing the shared authentication path.
The same report places normal Copilot token traffic at 7-9 thousand requests per second and incident traffic at 70-100 thousand. It attributes that amplification to a latent VS Code retry defect. These are GitHub's operational figures, not measurements collected by PeopleAreGeek.
The CTO's August 20 explanation says the incident began with capacity pressure rather than a newly introduced code or configuration change. An unchanged configuration can still become inadequate as demand grows.
Why adding capacity can be insufficient
Consider a separate, fictional service receiving 1,000 original operations per second. If each operation produces its first attempt plus nine retries during persistent failure, the receiving tier sees up to 10,000 attempts for those operations. It has not acquired ten times as many users; it has acquired ten times as much attempted work.
This arithmetic assumes all ten attempts occur and says nothing about GitHub's exact retry algorithm. It illustrates why counting original operations and counting attempts answer different questions. Retry delay can spread attempts in time, while a retry budget limits how much additional work is admitted. Neither should be confused with unlimited retrying until success.
Monitor the dependency that carries the requests
A proposed service-mesh review records separate demand and capacity signals for the application, sidecar and gateway. Include concurrent requests, queues and failures where the component exposes them. Healthy application CPU alone cannot rule out an exhausted proxy connection or concurrency limit.
Then rehearse a bounded dependency failure in a test environment. Observe whether retries consume the recovery headroom and whether the caller eventually stops. Use safe test operations; retrying a write may have different consequences from retrying a read.
The duration is not a uniform blackout
The incident record spans 13:28-21:15 UTC. Most services recovered earlier, while Actions and Copilot needed further recovery work. A single duration is useful for the incident envelope, but it should not be read as every request failing for that entire interval.
GitHub lists scaling-policy corrections, retry review and improved capacity monitoring among its follow-up actions. Those commitments describe work to improve reliability; they do not erase the incident or guarantee that every similar failure mode is now impossible.
Use the official incident report, distinguish overall duration from component recovery, and illustrate retry multiplication without inventing measurements.