GitHub has resolved a critical outage that disrupted much of its development platform for seven hours and 35 minutes on August 17. At the incident’s peak, the company reported error rates of about 20% across its website and API traffic, while downloads of repository archives and raw files were failing roughly half the time. The disruption reached pull requests, issues, Actions, webhooks, Git operations, Pages, Copilot, and enterprise identity services.
The breadth matters more than whether every request failed. GitHub is where many teams store code, but it is also where they review it, test it, deploy it, manage access, and trigger external systems. A partial failure across those layers can stop a software delivery pipeline even when developers still have complete local copies of their repositories.
According to GitHub’s official incident record, the incident began at 13:40 UTC and was declared resolved at 21:15 UTC. GitHub says a detailed root-cause analysis will follow. Until that appears, there is no sound basis for calling this a database failure, a bad deployment, an attack, or any other specific cause. The public record supports only GitHub’s description of a problematic component and a recovery complicated by residual authentication failures.
A degradation that spread quickly
GitHub’s first notice said only that some services were performing poorly. Within six minutes, the status page had separately flagged API requests, Actions, webhooks, and issues. Pull requests followed. By 14:04 UTC, GitHub was reporting the 20% error rate for web experiences and API traffic and the roughly 50% failure rate for archive and raw-content downloads.
That mix could interrupt work in several different ways. A developer might still edit and commit code locally but fail to push it. A reviewer could be unable to load a pull request. An automation service waiting for a webhook might never receive the event it expected. A build could fail to start, fail while fetching a dependency from GitHub, or become impossible to inspect through the Actions interface. None of those outcomes requires GitHub to be completely offline.
The incident became more severe as it continued. Copilot was marked as suffering a major outage at 14:31 UTC. Issues, pull requests, and Actions later moved from degraded performance to major-outage status, while webhooks reached partial-outage status. API requests were classified as a major outage at 15:01 UTC, and Git operations were reported degraded 20 minutes later. Pages was also affected.
GitHub additionally named SAML and OIDC authentication, SCIM provisioning, and Team Sync among the impacted systems. Those are not secondary conveniences for organizations that use centralized identity. They sit on the path by which employees and automated workloads prove who they are and receive the right access. Their inclusion helps explain why one incident could show up as failures in both human-facing tools and machine-driven workflows. It does not, by itself, reveal the underlying fault.
Recovery came in stages, then slipped backward
At 16:36 UTC, nearly three hours after the incident began, GitHub said it had identified the problematic component and taken corrective action. The company saw strong signs of recovery but warned that error rates remained elevated. At 16:59, it marked API requests, Actions, Git operations, issues, Pages, pull requests, and webhooks operational again. Copilot remained in major-outage status.
That was not the end. Git operations degraded again at 17:30, followed by issues. GitHub described residual impact across multiple services and later narrowed part of the problem to sporadic authentication failures. Git operations recovered at 18:23, but API availability degraded again at 18:48 before returning to normal 13 minutes later.
The most revealing mitigation update came at 19:13. GitHub said it had partially disabled authentication-token retries, saw improvement, and was monitoring the effect before applying that mitigation fully. This is evidence that retry behavior was involved in the lingering impact, not proof that retries caused the original outage. In distributed systems, retries can help clients ride through transient errors, but poorly bounded retry traffic can also prolong pressure on an unhealthy dependency. GitHub has not said which of those dynamics applied here.
At 20:08, GitHub said it was still investigating sporadic Copilot authentication failures in some applications, while issues also remained marked as degraded. Copilot through the GitHub CLI and GitHub App was unaffected at that stage. Issues returned to normal at 20:22, and GitHub declared the entire incident resolved 53 minutes later.
Git stayed distributed; the workflow did not
There is an important distinction between Git and GitHub during an outage. Git is a distributed version-control system. As the official Pro Git book explains, a clone normally contains the repository’s full history, so most version-control work can continue locally without a server connection. Existing clones did not stop being repositories on August 17. Developers could still inspect history, create branches, make commits, and compare changes on their machines.
Modern engineering workflows, however, commonly centralize nearly everything around the hosted remote. Code review lives in pull requests. Tests and releases run in Actions. Issue state drives planning. Webhooks connect the repository to chat systems, deployment services, security scanners, and internal tooling. Copilot adds another hosted dependency inside the editor. Enterprise identity decides whether people and services can reach any of it.
The result is an asymmetric failure mode: code authoring may continue while coordination and delivery stall. That is better than losing access to the code itself, but it can still block releases, incident fixes, and routine maintenance. Teams that describe GitHub only as a source-code host are understating its operational role.
The quiet risk is missed automation
Once a status page turns green, queued and event-driven work deserves separate attention. GitHub’s documentation for failed webhook deliveries says failed deliveries are not automatically redelivered. Administrators can retry them manually or build a process to detect and redeliver failures.
The incident record does not establish that any particular customer lost webhook events. It does establish that webhooks were degraded and then partially unavailable. Teams whose deployment, synchronization, or audit processes depend on them should therefore reconcile the outage window instead of assuming service restoration filled every gap. The same principle applies to failed or missing CI runs: compare expected work with completed work, then rerun only what is safe to repeat.
This is also a reason to design automation around idempotency, meaning that repeating an operation does not create a second, conflicting outcome. A retryable deployment job is safer when it can recognize that an artifact was already published. A webhook consumer is easier to recover when it records event identifiers and can reject duplicates. Those practices are useful during ordinary network failures, not just a platform-wide incident.
What engineering teams can take from the outage
No team needs to recreate GitHub to reduce its exposure. The practical response is to decide which work must continue when the collaboration platform is impaired. Local clones already provide a strong base. Critical runbooks and emergency contact paths should also be reachable outside the affected service. Release processes should make their external dependencies visible, including code hosting, identity, package downloads, CI, and webhook-driven integrations.
Operational monitoring should treat GitHub’s components separately. An operational homepage does not guarantee that Actions, authentication, raw downloads, or Copilot are healthy, and this incident changed shape several times during recovery. Teams can also avoid making a bad period worse by using bounded retries with backoff rather than tight loops against failing APIs.
The larger lesson is not that hosted development platforms are uniquely fragile. It is that convenience has concentrated many distinct functions behind one provider and one identity plane. That concentration is often a rational trade, but teams should account for it in recovery plans just as they would for a cloud region, payment processor, or communications provider.
What comes next is GitHub’s promised root-cause analysis. The useful details will be what the problematic component was, why failures crossed so many product boundaries, how authentication retries interacted with recovery, and why services degraded again after the first mitigation. Until GitHub supplies that account, the status timeline shows the impact and the uneven restoration clearly, but it does not explain the initiating fault. That distinction is the one to preserve as teams review their own missed builds, webhook deliveries, and access failures.