GitHub Came Back Before Copilot Did

GitHub's August 17, 2026 outage lasted 7 hours 36 minutes, with Copilot being the last service to recover, clearing only when the incident closed at 21:15 UTC. The incident, which began at 13:40 UTC, degraded eight services including git operations, Actions, and Copilot, and saw three services relapse after an initial mitigation declaration at 16:59 UTC. GitHub had not disclosed a root cause at the time of writing.

The GitHub outage of August 17, 2026 opened at 13:40 UTC on a Monday morning US time, degraded eight named services including git operations, Actions, and Copilot, and resolved at 21:15 UTC — 7 hours 36 minutes end to end. Inside that window sits a more useful story than the outage itself: the order in which things came back. At 16:59 UTC, GitHub declared seven services mitigated. Copilot was not on the list. Three of the seven then relapsed — Issues, degraded for a second time, stayed impaired for another 2 hours 46 minutes — and the incident’s final three hours narrowed to a single residual failure: Copilot authentication, failing in some applications while the GitHub CLI and the GitHub App kept working. This post walks the timeline from the final incident record, then pulls out the transferable lessons: why an AI assistant sits on a different dependency chain than the git hosting next to it, which parts of a development loop silently degrade to manual, how to tell an incident from a rate limit, and why per-component status beats a single green light. GitHub had not disclosed a root cause at the time of writing, so nothing here speculates about one. - 01The incident ran 7 h 36 m; Copilot cleared last.Opened 13:40:03 UTC, resolved 21:15:46 UTC on August 17. Copilot was flagged at 14:31 UTC and was the one component absent from the 16:59 UTC “mitigated” list — it cleared only when the incident closed, 6 h 44 m after it was flagged. - 02“Mitigated” is not “recovered.”After the 16:59 UTC declaration, Git Operations relapsed for 53 minutes, Issues for 2 h 46 m, and API Requests for 13 minutes. A status component that flips green can flip back — treat mitigation declarations as provisional. - 03The residual failure was an authentication path.GitHub’s final updates narrowed the remaining impact to “sporadic Copilot authentication failures in some applications,” while stating that Copilot via the GitHub CLI and GitHub App was unaffected — the same service degrading unevenly by client. - 04The model-serving component was never named.GitHub tracks “Copilot AI Model Providers” as its own status component. None of the incident’s 36 updates names it, and its component log showed no change at a late-evening check — consistent with an auth/routing failure, not a model-inference failure. - 05Root cause: undisclosed, so audit your own chain instead.GitHub promised a detailed root cause analysis but had published none at the time of writing. The actionable work is on your side: know which parts of your loop degrade to manual, whether CI depends on an assistant, and which client paths you can fall back to. 01 — The TimelineSeven and a half hours, 36 status updates. The record is unusually clean because GitHub’s status page https://www.githubstatus.com publishes every incident as machine-readable JSON. The incident page https://www.githubstatus.com/incidents/zkxwbgr0cnmx for “Incident with GitHub.com” — impact level: critical — logs 36 updates between 13:40:03 UTC and the resolution notice at 21:15:46 UTC. The first hour was accumulation. API Requests was flagged at 13:41, Actions at 13:42, Webhooks at 13:44, Issues at 13:46, Pull Requests at 13:58, Copilot at 14:31, Pages at 15:10, and Git Operations at 15:21. By 13:45 GitHub was reporting “an approximate 20% error rate across numerous experiences” — its own stated figure for web and API traffic — and by 14:04 a vendor-stated ~50% error rate specifically on archive downloads and raw repository content. At 14:24 the update added that SAML and OIDC authentication, SCIM, and Team Sync were also impacted. At 16:36 UTC came the turn: “We identified the problematic component and have taken corrective actions.” At 16:59 UTC, seven services were declared mitigated. Then the messy part started — three relapses, an authentication residue, and another 4 hours 16 minutes before the incident actually closed. final incident record on GitHub’s status API after the incident was marked resolved at 21:15:46 UTC on August 17, 2026 — the timeline here is the closed record, not a mid-incident snapshot. GitHub’s resolution notice states: “A detailed root cause analysis will be shared as soon as it is available.” At the time of writing, none of the incident’s 36 updates discloses a cause, and none of the three press reports we checked BleepingComputer, Cybersecurity News, CyberKendra reports one either. Independent corroboration of the opening timeline exists: BleepingComputer https://www.bleepingcomputer.com/news/microsoft/microsoft-confirms-github-is-down-worldwide/ , Cybersecurity News https://cybersecuritynews.com/github-outage-worldwide/ , and CyberKendra https://www.cyberkendra.com/2026/08/github-down-outage-actions-api-copilot.html each independently confirmed the 13:40 UTC start, the 14:31 UTC Copilot flag, and the vendor-stated error-rate figures while the incident was live. One calendar note, offered strictly as coincidence: Cursor’s Origin code hosting entered early beta /blog/cursor-origin-early-beta-code-hosting-github-sync the same day. Nothing in the incident record or in any source we checked connects the two events, and we draw no link beyond the shared date. 02 — The 16:59 ListSeven services mitigated — one name missing. The 16:59 UTC update is the hinge of the whole incident, and it rewards a careful read. Seven services are named. Copilot — flagged with degraded availability at 14:31 UTC, two and a half hours earlier — is not among them. “The degradation affecting API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks has been mitigated. We are monitoring to ensure stability.”— Incident update, 16:59 UTC, August 17, 2026 That omission was not an oversight in the wording; it was the shape of the remaining problem. From 18:11 UTC the updates describe “residual impact in the form of sporadic authentication failures.” At 19:13, GitHub reported it had “partially disabled authentication token retries” and seen improvement. At 20:08 the residue was narrowed all the way down: “sporadic failures affecting Copilot authentication in some applications,” with the same update stating that “Copilot usage via the GitHub CLI and GitHub App are unaffected.” The 20:45 update repeated that scoping, projected full recovery within 30 minutes, and the incident resolved at 21:15 — about 30 minutes later, as projected. So the last three hours of a critical-impact incident were, in the end, about one thing: an AI assistant’s authentication path, failing for some client applications and not others. Git push worked. The website worked. Whether your Copilot session worked depended on which client you were holding. 03 — RelapsesMitigated is not recovered. If the 16:59 list is the hinge, the relapses are the lesson. Three of the seven services on that list fell back over within two hours of being declared mitigated. Git Operations went back to degraded performance at 17:30 and was re-mitigated at 18:23 — a 53-minute relapse. Issues relapsed at 17:36 and was not reported operating normally until 20:22 — a second impairment of 2 hours 46 minutes. API Requests dropped to degraded availability at 18:48 and recovered at 19:01 — 13 minutes. Every figure here is computed from the incident record’s own timestamps. | Component | First flagged UTC | On the 16:59 list | Relapse window UTC | Final clear UTC | |---|---|---|---|---| | Mitigated at 16:59 and stayed clear | |||| | Actions | 13:42 | Yes | None recorded | 16:59 | | Webhooks | 13:44 | Yes | None recorded | 16:59 | | Pull Requests | 13:58 | Yes | None recorded | 16:59 | | Pages | 15:10 | Yes | None recorded | 16:59 | | Mitigated at 16:59, then relapsed | |||| | Git Operations | 15:21 | Yes | 17:30 → 18:23 53 min | 18:23 | | Issues | 13:46 | Yes | 17:36 → 20:22 2 h 46 m | 20:22 | | API Requests | 13:41 | Yes | 18:48 → 19:01 13 min | 19:01 | | Never on the 16:59 list | |||| | Copilot | 14:31 | No — absent from the update | Impaired continuously; auth residue from 18:11 | 21:15 incident resolution | Two operational readings follow. First, a mitigation declaration starts a clock — it does not end one. If your team stood down at 17:00 UTC because the dashboard went green, Issues fell over again 36 minutes later and stayed impaired for the rest of the working day in US time zones. A sensible convention is to treat any “mitigated” as provisional for at least an hour and keep whatever fallback you switched to warm. Second, relapses cluster where load returns: the record cannot tell us why these three components relapsed — no root cause is public — but it plainly shows that recovery was not monotonic, and monitoring that assumes it is will mislead you exactly when it matters. Time from incident open 13:40 UTC to each component's final clear Source: computed from the final incident record's timestamps, githubstatus.com incident zkxwbgr0cnmx 04 — Dependency ChainsYour assistant lives on a different chain. Here is the detail that makes this incident worth a post rather than a shrug. GitHub’s status page tracks “Copilot AI Model Providers” — the model-serving backend — as its own component, separate from “Copilot” the product surface. None of the incident’s 36 updates names the model providers component, and at a late-evening check while Copilot itself still showed a major outage, that component’s log showed no status change during the incident at all. Put the pieces together — no logged status change on the model-providers component, CLI and GitHub App fine, “some applications” failing, the fix involving authentication token retries — and the shape of the failure is visible without any speculation about its cause: the impaired link was an authentication path between certain client applications and the service , not the assistant as a whole. Availability degraded unevenly by client. Two developers on the same team, same account, same service, could have opposite experiences depending on which surface they invoked Copilot from. 14:31 → 21:15 UTC The longest single-component span of the incident: flagged at 14:31 UTC, absent from the 16:59 mitigation list, cleared only when the incident resolved at 21:15 UTC. Elapsed: 6 h 44 m, versus 3 h 20 m for the four components that recovered cleanly. status changes logged GitHub tracks “Copilot AI Model Providers” as a separate status component. None of the 36 incident updates names it, and its component log showed no change at a late-evening check during the incident — consistent with an auth/routing failure rather than a model-inference failure. named by GitHub The 20:08 and 20:45 UTC updates both state that Copilot via the GitHub CLI and the GitHub App was unaffected while “some applications” still hit sporadic authentication failures — one service, uneven availability by client path. different dependency chain than git hosting: authentication and token flows, request routing, and provider capacity, each of which can fail while repositories, CI, and the models themselves stay healthy. On August 17 the git host and the assistant shared an incident and still recovered on different clocks. When they don’t share an incident, the gap will be wider. The interpretation we’d offer: status pages and architecture diagrams still treat “the assistant” as one box, and August 17 shows it is at least three — client auth, routing/product surface, and model serving — each able to fail independently. The practical consequence is that “is Copilot up?” is no longer a well-formed monitoring question. “Is Copilot up from this client, on this auth path ?” is. That reframing — not any fact about GitHub’s infrastructure — is what transfers to every assistant vendor your team depends on. 05 — Degrade To ManualKnow what degrades to manual — and what just stops. An assistant outage is not one failure; it is a different failure for each place the assistant sits in your loop. The useful audit takes an hour: list where an assistant participates in your development workflow, and for each, ask what happens when it returns errors for seven hours on a Monday. Four archetypes cover most teams. Completions and IDE chat Fails visibly and degrades gracefully — you type the code yourself. The cost is velocity, not correctness. The main risk is developers context-switching to debug “their” setup instead of recognizing a provider-side event. PR summaries and assistant review Degrades quietly. If assistant review is a soft habit rather than a required check, PRs merge with less scrutiny during the outage window and nobody logs that it happened. Decide in advance: block, or merge with a human-review label. Pipeline steps that call an assistant Fails hard. A CI step that shells out to an assistant turns a provider incident into a merge blocker for every branch. If any step does this, it needs a documented skip path with an audit trail — before the incident, not during it. Bots for triage, labels, release notes Fails silently and piles up. Issue-triage and changelog bots that drop events during an outage leave gaps you discover weeks later. Prefer queue-and-replay designs over fire-and-forget calls to the assistant. The August 17 twist sharpens the audit: because the residual failure was per-client, your fallback may be another client rather than no assistant. A team whose IDE integration failed that evening but whose workflow could shell out to the CLI had a degraded-but-working path — GitHub itself was pointing users there in its final updates. Knowing which alternate client paths exist for each assistant you run is cheap resilience. For the general incident-response machinery — roles, comms, decision trees — we’ve already written the agentic workflow incident-response playbook /blog/agentic-workflow-incident-response-playbook-2026 , and this post deliberately doesn’t rebuild it. 06 — Incident Or Rate LimitThree failure signatures that look identical from the IDE. From inside an editor, “the assistant stopped responding” is one symptom with at least three causes that demand different responses. Teams that can tell them apart in five minutes save the afternoon; teams that can’t burn hours debugging their own configuration during a provider incident — or file an incident when they’ve simply hit a quota. Provider incident Fails for multiple people on different accounts at once, error shapes vary 5xx, timeouts, partial responses , and the vendor's status page components start flipping. Response: switch to your fallback path and stop debugging locally. Rate limit Scoped to one account or key, returns explicit 429-style errors with retry-after semantics, and resets on a schedule. Response: back off and queue. Escalating a quota exhaustion as an outage wastes everyone's time. Auth-path failure August 17's residue: some client applications fail sporadically while the CLI and first-party app keep working — same account, same service. Response: try a second client path before declaring the assistant down. The third signature is the newest and the least covered by existing runbooks. Sporadic auth failure is nastier than a clean outage precisely because it is intermittent and uneven: retries sometimes succeed, one teammate reproduces it and another can’t, and the natural conclusion is a local misconfiguration. The tell on August 17 was on the status page — a per-component feed that kept Copilot flagged from 14:31 UTC onward and, from 20:22, showed it as the only component still impaired. Which is the argument for the last section. 07 — Before The Next OnePer-component status beats a single green light. A single overall indicator would have told you GitHub had a bad day on August 17. The component-level feed told you what to actually do, hour by hour: when git operations were safe again, when Issues relapsed, and that once Issues was reported operating normally at 20:22 the only thing standing between your team and normal work was Copilot auth on certain clients. Most vendors expose this granularity — GitHub’s unresolved-incidents endpoint https://www.githubstatus.com/api/v2/incidents/unresolved.json is public JSON, no authentication required. Concretely, before the next incident: subscribe to component-level status for every assistant and host on your critical path, not just the front page; wire the two or three components you actually depend on into your alerting; write down your per-surface fallback paths from Section 05; and set the “mitigated is provisional” convention from Section 03. For measuring how well you did afterwards, our MTTR/MTTD framework for AI incidents /blog/ai-incident-metrics-mttr-mttd-framework-agentic-2026 covers the metrics side; the Claude outage resilience playbook /blog/claude-ai-outage-march-2026-enterprise-resilience-playbook from March covers assistant-vendor outages from the customer side; and the platform outage readiness playbook /blog/ecommerce-platform-outage-resilience-2026-incident-readiness-playbook covers the same discipline for commerce stacks. Looking forward, the direction of travel is one-way: more of the development loop is moving onto assistant dependency chains, not less — review gates, CI steps, triage bots, agents that open their own PRs. Every one of those additions puts an auth flow, a routing layer, and a provider-capacity pool between your team and a merged pull request. Incidents like this one will not become rarer as that surface grows; the teams that handle them well will simply be the ones that mapped their chains before the status page forced the issue. If you want a structured pass over where AI now sits in your delivery pipeline — and what should happen when any link in it fails — that is exactly the kind of audit our AI transformation engagements /services/ai-transformation start with. 08 — ConclusionThe outage ended. The dependency didn’t. Your assistant recovers on a different clock than your git host. The August 17 incident resolved in 7 hours 36 minutes, and on GitHub’s own record the recovery was staggered and messy: seven services declared mitigated at 16:59 UTC, three relapses, and a final three hours spent on one authentication path that failed unevenly across Copilot clients, while GitHub’s separate model-providers component was never named in any of the 36 updates. No root cause was public at the time of writing, and none of the lessons here depends on one. The lessons are structural. An AI assistant on your critical path is a distinct dependency with its own failure modes — auth, routing, provider capacity — and it can be the last thing to recover even when it shares an incident with your git host. “Mitigated” is a provisional state, not a resolution. And the difference between a wasted afternoon and a managed one was available for free the whole time, in a per-component status feed. The work, then, is not predicting the next incident — it is making your own dependency map honest before it happens. Know which surfaces degrade to manual, which fail hard, which client paths give you a fallback, and which components of which vendors deserve a permanent place in your alerting.