GitHub Outage: 8-Hour Disruption Hits Actions, APIs, Copilot

What happened

GitHub has resolved a nearly eight-hour outage that disrupted core parts of its platform, including Actions, pull requests, APIs, Git operations, Webhooks and its Copilot AI assistant. The incident began at 1:40 PM UTC on 17 August, when GitHub first flagged degraded performance, and quickly widened to affect API requests, Issues, PRs and Webhooks within minutes.

At its peak, GitHub reported an error rate of roughly 20% across its web and API traffic, with archive downloads and raw repository content downloads seeing error rates of around 50%. SAML and OIDC authentication, SCIM, and Team Sync were also affected, alongside disruption to Copilot. GitHub confirmed resolution via its status page, thanking users for their patience while the issue was addressed.

Why it matters

GitHub sits at the centre of software development workflows for millions of engineering teams globally, so an outage of this breadth — touching version control, CI/CD pipelines, authentication and AI-assisted coding simultaneously — has an outsised operational ripple effect. Teams relying on Actions for automated builds and deployments, or on Copilot for day-to-day coding assistance, would have faced stalled release cycles and reduced productivity for the better part of a working day.

For organisations increasingly dependent on cloud-hosted developer infrastructure and AI coding tools, the incident is a reminder that resilience planning must extend beyond customer-facing systems to the tooling that underpins internal engineering operations. When a single platform outage can simultaneously degrade authentication, deployment and AI assistance, the blast radius of a dependency failure becomes a board-level risk, not just an engineering inconvenience.

By the numbers

• Nearly 8 hours — total duration of the outage, from first report to resolution.
• 1:40 PM UTC on 17 August — when GitHub first flagged degraded performance.
• ~20% — peak error rate across GitHub's web experience and API traffic.
• ~50% — peak error rate for archive downloads and raw repository content downloads.

The Renascence take

Outages at infrastructure-level providers rarely make headlines the way consumer-facing failures do, yet their downstream effect on service delivery is often larger and harder to see. The real story here isn't the outage itself — it's what it reveals about how invisible dependencies shape the experience customers eventually receive.

Most organisations map customer journeys but rarely map the technical dependencies that make those journeys possible — and an eight-hour disruption to a developer platform is a useful proof point for why that gap matters. When core tooling for authentication, deployment and AI-assisted work fails at once, the damage isn't just lost engineering hours; it's delayed features, paused fixes and slower support for the end customers waiting on the other side of that pipeline. A customer-obsessed operator treats third-party platform risk as a service-design problem, not just an IT one: build visible fallback paths, communicate proactively when a dependency falters, and rehearse degraded-mode operations before they're forced upon you.