GitHub opened an incident at 13:40 UTC on 17 August and did not declare full recovery until 21:15. Seven and a half hours, across most of the platform.
The list of affected services is the part worth reading closely, because it is broader than the ones people notice: API Requests, Actions, Git Operations, Issues, Pages, Pull Requests, Webhooks — and Copilot authentication.
What broke
The severity varied by service, and the numbers give a sense of what teams actually experienced:
- Around 20% error rates for web experiences and API traffic
- Roughly 50% errors on archive downloads
- SAML, OIDC authentication, SCIM and Team Sync impacted
- Sporadic Copilot authentication failures in some applications, with the CLI and the GitHub App unaffected
- Issues and Pull Requests degraded rather than down
The 20% number is the interesting one
A total outage is easy to understand: everything fails, you stop, you wait. A 20% error rate is worse to work through, because four out of five actions succeed.
That is the pattern that produces the confusing hours — a push works, the next fails, a retry works, CI is red for reasons unrelated to the code. Teams spend the first part of an incident like this debugging their own systems, because partial failure looks exactly like a bug on your side.
The practical lesson is small and repeatable: when something intermittent starts, check the vendor status page before you check your code. It costs thirty seconds and it is right more often than anyone expects.
Authentication was the long tail
GitHub identified a problematic component and took corrective action. Git Operations degradation was mitigated first, but residual authentication failures persisted after that.
That ordering is worth noting because authentication is the dependency that reaches furthest. SAML and OIDC failing does not just mean you cannot log in to GitHub — it means anything using GitHub as an identity provider is affected, and SCIM and Team Sync failing means group membership stops updating.
The Copilot detail is instructive too: authentication failures were sporadic and application-specific, with the CLI and the GitHub App unaffected. In an incident like this, "is it down?" has no single answer, which is why individual developers reported wildly different experiences.
What this is actually evidence of
Not that GitHub is unreliable — a seven-hour degradation is a bad day, not a pattern, and every platform at that scale has them.
What it is evidence of is concentration. On 17 August, one incident simultaneously affected where a large share of the industry stores code, runs CI, authenticates, and — newly this year — gets AI assistance. Five years ago those were four vendors and four separate bad days.
That consolidation was a deliberate choice by every team that made it, and mostly a reasonable one. It is just worth having noticed, ideally on a day when everything is working.
What to take away
Three things worth doing this week while it is fresh.
- Find out what your team could not do for those seven hours, and whether anything on that list should have a fallback
- Check whether your CI can distinguish an infrastructure failure from a test failure — if it cannot, every incident costs you debugging time on top of downtime
- If GitHub is your identity provider, know which internal systems go down with it; that list is usually longer than people expect