What happened
GitHub suffered a major service disruption on August 17 lasting 7 hours and 47 minutes, from 13:28 to 21:15 UTC, degrading core services including Issues, Pull Requests, APIs, Actions, and Copilot. According to reporting on the incident analysis, the trigger was a misconfigured autoscaling policy in a Central US facility: the policy monitored the host service but did not track the concurrency limit of an attached Istio sidecar, so when the sidecar hit its ceiling, no new capacity was added. From there, the failure compounded. Optimistic retry logic hammered internal load balancers, a latent bug in VS Code's retry behavior multiplied traffic to the Copilot Token Service roughly tenfold, and scraping activity against download endpoints made recovery harder. GitHub stabilized most services by mid-afternoon UTC after cutting gateway retries and temporarily rejecting Copilot token requests, though Copilot remained impaired until nearly the end. The company says it is correcting the autoscaling policies, reviewing retry limits, and addressing the client-side behavior that amplified the load.
Why it matters for your business
Plenty of DMV small businesses do not use GitHub directly, but the developers, agencies, and freelancers who build and maintain their websites and apps almost certainly do. For nearly a full workday, code reviews, automated deployments, and AI coding assistance were degraded worldwide, which is why a vendor may have quietly missed a deadline on August 17. There is also a broader operations lesson in the root cause: the outage was not a cyberattack but a monitoring blind spot plus well-intentioned retry logic that made everything worse, the same failure shape behind many cloud outages. If your business depends on a chain of SaaS tools, it inherits this class of risk.
What to do about it
- Ask your web or software vendor how an outage in their tools affects your deadlines, and how they communicate delays
- Subscribe to status pages for the handful of services your business truly depends on
- If you run your own systems, review what your monitoring actually watches; this outage hid in an unmonitored limit
- Treat aggressive automatic retries in any integration as a risk to tune, not a free reliability feature