GitHub outage caused by autoscaling misconfiguration and VS Code retry storm overloaded load balancers

The outage stemmed from a gap in GitHub’s autoscaling monitoring. The policy tracked host service metrics but ignored Istio sidecar concurrency limits, creating a blind spot. When sidecars hit their limits, the system failed to scale, and load balancers saturated under traffic. This demonstrates how distributed systems can fail at integration points, even when individual components appear healthy. Engineers should audit autoscaling policies to ensure they account for all dependent services, not just the primary workload.

The incident was compounded by a retry storm from Visual Studio Code. A latent bug in the client triggered excessive retries for Copilot token requests, amplifying traffic by an order of magnitude. This highlights the fragility of client-server interactions in SaaS ecosystems, where a single misbehaving client can degrade shared infrastructure. GitHub’s mitigation, blocking Copilot requests with HTTP 403s, was a blunt but effective stopgap. Teams should review retry logic in their own clients and consider circuit breakers to prevent similar amplification.

Recovery was further delayed by external factors, including scraping attacks on codeload endpoints. While GitHub’s post-mortem focuses on internal misconfigurations, the outage reveals how SaaS reliability can be undermined by both internal and external pressures. The incident also arrives as competitors like Cursor and OpenAI accelerate their own developer tooling, raising questions about GitHub’s long-term dominance. For engineers, this outage is a reminder to evaluate redundancy and failover strategies, especially for critical workflows like CI/CD and code hosting.