GitHub's seven-hour outage: your CI has one upstream

On August 17 GitHub degraded for roughly seven and a half hours. Web and API traffic ran near a 20% error rate. Archive and raw content downloads hit about 50%. If your deploy pipeline pulls a base image, an action, or a dependency from GitHub — and it almost certainly does — you were in the blast radius whether or not anyone on your team opened a pull request that day.

What actually happened

Per ITPro's timeline, the incident ran from roughly 13:40 to 21:15 UTC. Affected: API requests, Actions, webhooks, pull requests, issues, Copilot, SAML and OIDC authentication, SCIM, and Team Sync. Downdetector peaked near 3,000 reports. GitHub did not publish a cause during the incident and promised a root cause analysis when available; check GitHub Status for the current write-up.

The pattern is the story. ITPro counts eight other outages in the preceding month, including an Actions incident GitHub itself called unacceptable. GitHub has attributed the run of failures to infrastructure strain from AI-assisted coding demand, saying it first planned a 10x capacity increase and then concluded it needed 30x. Microsoft has committed to accelerating the migration of Actions onto Azure.

Why a single-upstream CI pipeline matters for your business

A 20% error rate is worse than a clean outage. Down is honest — your pipeline fails fast and you go do something else. One-in-five is a coin flip that produces flaky builds, half-populated caches, retried deploys, and an afternoon of engineers debugging their own code for a fault that is not theirs. Budget for the confusion, not the downtime.

SAML and OIDC going down is an access incident, not a build incident. If GitHub is your identity provider for other tools, or if your cloud roles trust GitHub's OIDC issuer for deploys, an outage locks you out of things that have nothing to do with git. Write down what currently authenticates through GitHub. For most small teams it is a longer list than expected.

The 30x number is the forecast you should plan against. GitHub is publicly saying agent traffic is thirty times what human developers generated. Every shared developer service you depend on — package registries, container registries, model APIs — is absorbing the same curve with the same lead time on capacity. Assume more of these, not fewer.

Three fixes, in order of effort. Pin and vendor your GitHub Actions instead of pulling @main at build time. Mirror the handful of repos and images your deploy path actually needs. And make sure one person can ship a hotfix without GitHub in the loop, even if the answer is an SSH key and a script.

Sources: ITPro, GitHub Status.