GitHub’s August 17 Outage Hit Downloads, Actions and Copilot—What We Know

GitHub’s August 17, 2026 outage disrupted far more than repository browsing. The incident affected web and API traffic, archive and raw-file downloads, Pull Requests, Issues, Actions, Webhooks, Git operations, Pages, GitHub Copilot and some enterprise authentication and provisioning features. At its peak, web and API requests were returning errors at about 20%, while archive and raw repository-content downloads were failing at roughly 50%.

The most important caveat is that the public record still does not establish the outage’s root cause. GitHub said it had identified a problematic component and was applying corrective action, but its status updates indicated that a detailed root-cause analysis would follow.

Timeline: from investigation to uneven recovery

GitHub began investigating reports of performance problems at approximately 13:40 UTC, or 9:40 a.m. EDT, on August 17. The disruption spread quickly across services that developers use to access code, review changes, run automation and deliver software.

GitHub later reported that it had identified the implicated component and taken corrective action. A recovery update published at 12:36 p.m. EDT said the platform was showing strong signs of recovery, although service had not yet completely stabilized.

Recovery was not simultaneous across the platform. GitHub’s status reporting showed major services returning to operational status while Copilot continued to experience authentication problems in some applications. Other incident reporting placed the overall disruption’s end at about 21:15 UTC, making the full incident substantially longer than the initial period of severe platform degradation.

How severe was the outage?

The clearest measure of impact came from GitHub’s reported error rates:

• Web experiences and API traffic: approximately 20% errors.
• Archive downloads and raw repository content: approximately 50% errors.
• Developer services: Pull Requests, Issues, Actions, Webhooks, Git operations and Pages were degraded or unavailable at different points.
• AI coding assistance: GitHub Copilot was affected and remained an active problem after several core services had recovered.
• Enterprise identity: reports indicated disruption to SAML and OIDC authentication, SCIM provisioning and Team Sync, potentially preventing organizations from reliably signing users in or managing access.

These figures describe error rates, not the percentage of all GitHub users who lost access. A 20% API error rate does not mean that exactly 20% of customers were offline, and the 50% download figure applies to the affected download requests rather than all repository traffic.

Why the timing made the disruption especially disruptive

The incident began on a Monday morning in the United States, overlapping with the start of the workweek for many engineering teams. That timing matters because source access, code review, continuous integration and deployment automation are often part of the first work cycle of the day. Actions, Pull Requests, APIs and Webhooks were among the affected services, so teams could encounter failures across several connected steps rather than in one isolated feature.

Outage-reporting totals also varied by time and tracker. One report cited more than 10,000 Downdetector reports by 8:12 a.m. Pacific, while another recovery report described a peak of nearly 3,000 reports. Those figures should not be treated as a precise count of affected users: outage trackers measure submitted reports, and totals change with geography, timing and reporting methodology.

What GitHub did—and what it has not explained

GitHub’s public updates establish three parts of the response:

1. Engineers investigated elevated performance problems across multiple services.
2. The company identified a problematic component and took corrective action.
3. GitHub continued applying mitigations after the main platform services began recovering, including work on sporadic Copilot authentication failures.

The available evidence does not identify the component, describe the exact corrective action or prove that capacity pressure caused this specific incident. AI-driven traffic growth and infrastructure constraints are part of GitHub’s broader reliability discussion, but they should not be presented as the confirmed root cause of the August 17 outage before the promised postmortem is available.

How this fits GitHub’s wider 2026 reliability troubles

The August incident arrived after a difficult reliability period. GitHub’s July availability report documented eight incidents during the month. One July 8 incident lasted more than seven hours and affected the Web UI, REST API, GraphQL API, Actions, Packages, Copilot and Git operations in some Enterprise Cloud environments.

GitHub has also described a larger infrastructure challenge. In its availability messaging, the company said traffic was growing rapidly, driven in substantial part by AI-assisted and agentic development workflows. Its stated responses included moving more capacity to Azure, separating services and reducing shared failure points.

The scale of the planned response is notable. Reporting on GitHub’s infrastructure plans said the company’s original 10× capacity target had been revised to a requirement to design for 30× its then-current scale. Other reporting described efforts involving Azure and additional multicloud capacity, including AWS, although those plans do not by themselves explain the August incident.

That context makes the outage significant beyond one bad morning. GitHub is not only a place to store Git repositories: it is also a collaboration layer, an automation platform, an identity system and an AI coding service. When shared dependencies fail, a single incident can interrupt repository access, reviews, builds, deployments, webhooks and coding assistance at the same time.

What organizations should take from the incident

The outage does not prove that developers are about to abandon GitHub, and the evidence does not support predicting an imminent migration wave. It does show why organizations that depend on GitHub for production delivery should review their failure assumptions.

Practical safeguards include maintaining repository backups or mirrors, keeping CI/CD configurations portable, documenting emergency release procedures and ensuring teams know how to operate when SSO, webhooks or hosted runners are unavailable. Those measures do not eliminate platform risk, but they can reduce the blast radius of the next service disruption.

The final judgment on August 17 will depend on GitHub’s postmortem. Until that analysis is published, the defensible conclusion is narrower: GitHub experienced a broad, cascading service disruption with severe effects on repository downloads and connected developer workflows, recovered in stages, and has not yet publicly explained the underlying failure.