The GitHub outage on 17 August 2026 knocked out core services for developers worldwide, with error rates hitting around 20% across the platform’s web experience and API traffic, and climbing to approximately 50% for archive and raw repository content downloads. What began as a performance investigation became a rolling, multi-hour incident that eventually pulled Copilot into its scope.
How the GitHub outage August 2026 unfolded
According to Dev.to, the outage started around 13:25 UTC. GitHub opened a critical-impact incident at 13:40 UTC, as reported by Digital Applied, meaning the platform itself acknowledged the severity within roughly 15 minutes of the first signs of trouble. That is a reasonably swift call for a company operating at GitHub’s scale, though cold comfort for the developers already staring at server errors.
GitHub’s status page showed the blast radius spreading quickly. API Requests, Actions, Webhooks, Issues, and Pull Requests all moved into degraded status. Authentication services were also caught up in it: SAML and OIDC authentication, SCIM, and Team Sync were all listed as affected. Then, at 10:31 AM EDT, GitHub confirmed that Copilot was experiencing degraded availability too, widening the incident to cover its AI coding assistant.
At 11:42 AM EDT, GitHub said it had begun mitigating the problems, though error rates at that point remained stubbornly unchanged: still around 20% for web and API traffic, still around 50% for archive and raw content downloads.
What was affected and when services recovered
The range of affected services made this outage particularly disruptive for teams with automated workflows. GitHub Actions was among those experiencing degraded performance, meaning CI/CD pipelines (automated builds, tests, and deployments) were unreliable for an extended window. Webhooks being down compounds that problem, because integrations that listen for repository events would have been receiving nothing, or receiving errors.
Git Operations, Packages, Pages, and Codespaces were listed as operational during the incident, which gave some developers a partial lifeline. But with Pull Requests, Issues, and the core web experience all degraded simultaneously, day-to-day collaborative work was effectively stalled for a significant portion of users.
According to Digital Applied, a meaningful milestone arrived at 16:59 UTC, when the degradation affecting API Requests, Actions, Git Operations, Issues, Pages, Pull Requests, and Webhooks had been mitigated. That represented the bulk of the services that had been visibly broken for most of the outage window. The full incident was then marked resolved at 21:15:46 UTC on 17 August 2026, also per Digital Applied, putting the total duration of the critical-impact incident at just under eight hours from the time GitHub opened it.
GitHub had not disclosed the root cause during the period covered by these updates, and its investigation was listed as ongoing. The lack of a public explanation is fairly standard practice during a live incident, but it will leave platform-reliability teams waiting on a post-incident review before they can properly assess their own exposure.
For context on the scale of disruption: a 50% error rate on repository archive downloads is not a nuisance figure. Teams using download-based package resolution, or any CI pipeline fetching source archives rather than cloning via Git, would have been hitting failures on roughly every other attempt. Combined with Actions being degraded, that is a compounding problem that can cascade across build systems in ways that take time to unwind even after the underlying service recovers.
GitHub has not, at the time of writing, published a full post-mortem. Given the breadth of affected services and the eight-hour resolution window, one is expected, and the platform’s engineering blog has historically been fairly candid about incident timelines when it eventually files them.
