LaunchGate Demo Report · Incident Teardown
GitHub 17.08 Outage (7h 47m): Why Autoscaling Policies Fail Under Burst Load
An architectural teardown of a systemic failure: autoscaler signal mismatch (Host CPU vs Sidecar Concurrency), 10x client retry storm amplification, and an authoritative LaunchGate validation verdict.
NO_GO — Saturated Control Loop
Failure classification: Asymmetric control signal mismatch + cascading retry amplification (Component Substitution Fallacy).
What Happened on August 17, 2026: 7 Hours 47 Minutes of Downtime
On August 17 at 13:28 UTC, GitHub experienced an extended global outage affecting GitHub Copilot and dependent services. According to GitHub's official post-mortem, the autoscaler was monitoring the host service rather than the sidecar's concurrency limit. As a consequence, the autoscaler viewed the system as healthy and refused to provision additional capacity.
The situation was drastically amplified by a bug in the VS Code client which, upon dropping a token streaming session, immediately reconnected without exponential jitter, amplifying Copilot token traffic by approximately 10x. A transient load spike escalated into a self-reinforcing thundering herd that saturated ingress routing for nearly 8 hours.
Component Substitution Fallacy: Why the Autoscaler Went Blind
Reliability researcher Lorin Hochstein (Surfing Complexity) highlighted the core vulnerability: every autoscaling policy is an operational control system with bespoke parameters. Teams frequently fall victim to the Component Substitution Fallacy, assuming that if the primary application CPU is within bounds, the entire composite entity (Sidecar + TCP Stack + Connection Pool + Process) possesses proportional headroom.
«Every autoscaling policy is effectively bespoke. This means that a team that owns a service is not only responsible for the business logic, but also for an operational control system with custom parameters, that can really only be checked via load testing.»
How LaunchGate Detects This Before Production
During a synthetic burst profile run, LaunchGate validates both application latency and the responsiveness of the underlying infrastructure control loop.
HPA watched host container CPU utilization. Scale-up threshold never tripped: CPU hovered at 48% while the proxy sidecar was actively rejecting connections.
The sidecar saturated its connection pool at 1.8x baseline load, long before pod autoscaling could trigger.
Client-side unjittered timeouts and immediate reconnect loops transformed a 15% transient degradation into a 10x self-inflicted DDoS.
Infrastructure reaction time lagged behind the burst slope by nearly an order of magnitude.
The service failed to return explicit backoff hints, maintaining hanging TCP connections and exhausting sockets.
How to Verify Your Cluster's Scaling Resilience in 1 Hour
Check your HPA YAML. If scaling relies strictly on CPU/Memory but pods utilize Envoy/Istio/Linkerd, monitor envoy_cluster_upstream_cx_active and pending queues. Connection saturation occurs well before host CPU limits.
Compare four numbers: (1) Sidecar max_connections, (2) Database connection pool ceiling, (3) Runtime worker pool, (4) OS open file limits (ulimit). The minimum is your true ceiling.
Execute a 5-minute step-burst test (0 to 3x baseline in 30 seconds). Simulate unjittered retries on 502/503/504. If the cluster deadlocks and fails to recover post-burst, your control loop is brittle.
Send your HPA config + expected burst profile
We will model your scaling bottlenecks, cross-reference Envoy/DB ceilings against your HPA triggers, and return an authoritative LaunchGate validation verdict (free for the first 5 teams).