The outage on GitHub.com that began at 13:40 UTC (22:40 JST) on August 17 was not limited to a simple failure to open repositories. GitHub reported an error rate of roughly 20% for the Web experience and API, and stated that about 50% of archive downloads and Raw repository content fetches failed. SAML/OIDC authentication, SCIM, and Team Sync were also affected, meaning that during the same window, disruption spread from the path developers use to read code, all the way to enterprise account access management and CI.
However, it would be a mistake to read that ~50% figure as "half of all git clone operations failed." Unless the denominators for each affected feature are kept separate, both the workarounds users should adopt and the scope of the incident that GitHub needs to explain after recovery become unclear. As of the official update at 20:45 UTC (05:45 JST on the 18th), core functionality had largely recovered, but the incident status remained "critical" and "investigating," with Copilot authentication failures persisting on some apps.
From 13:40 to 20:45: A Re-Degradation Even After Mitigation
At 13:45 UTC (22:45 JST), GitHub confirmed an error rate of roughly 20% across several operations, including Pull Requests and Issues. By 14:04 UTC (23:04 JST), the update was revised to state that the Web experience and API were showing roughly 20% error rates, while archive and Raw repository content retrieval were at roughly 50%. Even though the latter might look like the same "repository retrieval" as the former, it is not a figure measured across all Git operations.
The impact also extended to authentication systems. SAML/OIDC, SCIM, and Team Sync were added to the list of affected components, and from 14:31 UTC onward, Copilot moved into "major outage" status. Between 14:49 and 15:01 UTC, Issues, Pull Requests, Actions, and API Requests each entered "major outage" status. Pages and Git Operations were marked as "degraded" or "partial outage," meaning that for development teams, each stage of the pipeline—from review to publishing—became unstable at different times.
At 16:36 UTC (01:36 JST on the 18th), GitHub announced it had identified the problematic component and taken corrective action. By 16:59 UTC, the company reported that degradation had been mitigated for affected services, including API Requests, Actions, and Git Operations. Recovery was not linear, though: Git Operations degraded again between 17:30 and 18:23 UTC, and API Requests did the same between 18:48 and 19:01 UTC. Issues did not return to normal until 20:22 UTC.
As of the 20:45 UTC update, Copilot authentication failures remained on some apps. GitHub stated that Copilot usage via the GitHub CLI and GitHub App was unaffected by this remaining authentication issue. That said, this does not mean Copilot usage was unaffected throughout the entire incident. The company had expected full recovery within 30 minutes, but the issue had not been resolved by that point.
What the ~50% Figure Actually Refers To: Archive and Raw Retrieval
According to GitHub Docs, source archives generate tarball or zipball snapshots at the point of a branch, tag, or commit. These are distribution artifacts that do not include full history, and GitHub recommends using clone as the method for retrieving a repository along with its history. Therefore, the ~50% figure in this incident was a real-time estimate limited specifically to archive downloads and Raw repository content retrieval.
GitHub also listed Git Operations as degraded, but did not disclose a specific error rate for Git operations themselves. The ~20% figure, too, was a real-time estimate for the Web experience and API at that moment—not an average across the entire incident duration, nor a breakdown by region or contract tier. Statements such as "half of all repository retrievals failed" or "half of all git clone operations failed" go beyond what was officially reported as the scope of impact.
This distinction matters in practice. Teams that use archives as CI inputs or for release distribution, versus development environments that rely on cloning with full history, need to check different paths during an outage—even when accessing the same repository. Rather than lumping everything together as "GitHub is slow," incident response requires separately logging where failures occurred: Web/API responses, content retrieval, or Git Operations.
Impact Spanning from Code Retrieval to Enterprise Authentication
SAML single sign-on controls access to repositories, Issues, and Pull Requests within an Enterprise via an identity provider. SCIM handles user management, and Team Sync synchronizes IdP group membership with GitHub Team membership. GitHub reported SAML/OIDC authentication, SCIM, and Team Sync as within the scope of this incident. Beyond the UI and API, there was also a path through which organizational sign-in and permission propagation became unstable.
For example, granting access to new hires or revoking permissions for departing employees depends on operations that sync IdP groups with GitHub teams. If SAML/OIDC, SCIM, and Team Sync are simultaneously within the affected scope, then separately from whether code can be retrieved, the very process of determining who can access organizational resources may also stall. That said, since GitHub has not disclosed the number of individual customers actually affected, it's impossible to know exactly how much any given operational workflow was disrupted.
Disruptions to Actions, Webhooks, and API Requests compounded the problem further. Even for authenticated users, if post-push automation, notifications to external services, or internal integrations relying on the API stop working, the development workflow breaks down midway. The scope of this incident demonstrates that the availability of code hosting cannot be measured solely by whether stored data is intact.
Even After Migrating to Dedicated Infrastructure, User-Facing Paths Were Still Affected
According to the availability report GitHub published in July, there were 8 incidents that month. Read traffic for the monolith processed by Azure Central US reached 52.75% on July 28, and Git traffic processed by Azure rose to 47%, up from 43% in June. The official text does not limit this 47% figure to Central US alone. Reportedly, 29% of all repositories have a second replica in that same region. Additionally, a dedicated user service reportedly offloads over 1 million queries per second at peak from the shared path, and 80% of primary authorization lookup processing has already been moved to a separated path.
Regarding repository content, GitHub had explained that it was serving content entirely from dedicated Central US infrastructure. Even so, this time, approximately 50% of requests failed along the user-facing paths for archive and Raw content. What can be concluded from this combination of facts is that dedicating storage and delivery infrastructure does not necessarily fully isolate the end-to-end path—including authentication and request processing—from incidents. Since the specific problematic component and root cause remain undisclosed, it cannot be said that the dedicated infrastructure itself was the cause.
GitHub's CTO has stated that a plan to increase capacity tenfold began in October 2025, and that by February 2026, the company had determined it needed to plan for a future scale of 30 times current levels. Since late December 2025, agentic development workflows have reportedly surged, with Pull Requests now generating load that spans Git storage, Actions, and search, cutting across APIs and background jobs as well. The company believes that under high load, queue backlogs and cache misses amplify database load and retry traffic, causing slow dependencies to ripple across multiple user experiences. As a result, GitHub has been working on isolating critical services, reducing single points of failure, and designing systems that preserve partial functionality even during incidents. These are not explanations for the cause of this particular incident, but rather represent the broader pattern of incident propagation that GitHub has been working to address.
Root Cause Undisclosed: Testing the Effectiveness of Isolation Through Post-Incident Analysis
What GitHub has disclosed so far is only that it identified the problematic component and took corrective action. There is no information confirming that the Azure migration, AI development load, or authentication token retries were the definitive root cause of this incident. Nor had GitHub, as of the 20:45 UTC update, announced that no data was lost.
In its July report, the company stated it had processed 70% of read traffic and 30% of write traffic through Central US that quarter, and set a goal of migrating GitHub.com's production traffic away from its own data centers by the end of 2026. This is an ongoing plan, not a figure indicating completion. What needs to be verified from this incident is not simply how high the migration rate is, but rather how the malfunction of a specific component propagated across paths ranging from the Web to automation, and where retries, failover, and service isolation succeeded or fell short.
Once the final resolution time and post-incident analysis are published, it will be possible to cross-reference exactly which time windows and which paths the ~20% and ~50% figures represented, and what conditions triggered the re-degradation. As of 20:45 UTC, with the incident still unresolved, that explanation remains pending.