GitHub suffers a seven-hour multi-service outage affecting Git, Actions, and Copilot

GitHub experienced one of its longest and broadest outages in recent memory on Monday, with a cascading incident that began at 13:40 UTC and was still generating updates from GitHub's status page more than seven hours later. Microsoft, which owns GitHub, confirmed the outage as the list of affected services grew component by component throughout the afternoon.
How the Outage Spread
The incident started as a performance issue but expanded rapidly: API Requests went down at 13:41 UTC, Actions at 13:42, Webhooks at 13:44, Issues at 13:46, and Pull Requests by 13:58 — meaning within roughly 20 minutes, most of the core functionality developers rely on for daily work was degraded. At peak, GitHub's own status page reported error rates around 20% across web pages and API traffic, rising to roughly 50% on repository archive downloads and raw content requests — the kind of traffic consumed heavily by installation scripts, Docker image builds, and CI/CD pipelines pulling source from raw.githubusercontent.com.
At 14:24 UTC, the incident expanded again to include authentication: SAML and OIDC login, SCIM, and Team Sync were all affected, meaning organizations using single sign-on through GitHub could see login failures entirely separate from the repository-access issues. Seven minutes later, GitHub Copilot moved to degraded availability, adding Microsoft's AI coding assistant to the list of broken components. Git operations themselves — the core clone, push, and pull commands — were notably not affected during the earliest phase of the incident, though GitHub's status page later confirmed Git Operations also degraded around 17:30 UTC before being mitigated roughly an hour later.
A Long Tail of Partial Fixes
GitHub's status updates show a pattern of components recovering individually rather than all at once. By 16:59 UTC, the company reported that degradation across API Requests, Actions, Git Operations, Issues, Pages, Pull Requests, and Webhooks had been mitigated. But new issues kept surfacing: API Requests degraded again around 18:48 UTC before recovering roughly 13 minutes later, and authentication problems persisted well into the evening — as of 20:45 UTC, GitHub reported it was still working through sporadic Copilot authentication failures in some applications, with full recovery expected within another 30 minutes. The root cause of the initial incident has not been disclosed.
Why a GitHub Outage of This Length Matters
GitHub's scale makes an outage like this unusually disruptive across the software industry. Beyond the visible symptoms — developers unable to open pull requests or trigger CI/CD pipelines — the raw content and repository download degradation directly affects automated systems that don't have a human in the loop to notice and wait: build pipelines, container image creation, and package installation scripts that fetch dependencies directly from GitHub-hosted sources during the outage window would have failed or degraded silently, potentially affecting downstream deployments hours after the fact. For an outage spanning a full business day rather than the more typical 30-to-90-minute incident, the practical impact is measured less in a single dramatic failure and more in the accumulated friction of a full day where core developer infrastructure couldn't be fully trusted.
Originally reported by GitHub Status / IT-Connect. Read the original article for additional details.
View original source