What the GitHub Copilot outage means for legal AI tools

No cited source shows that Lexis+ AI, Westlaw, Harvey, Spellbook, or another named legal AI product was directly knocked offline by the August 17, 2026 GitHub Copilot outage. That is the first boundary to keep intact. The useful lesson is narrower and more practical: Copilot failed in a dependency class that legal drafting and research assistants also occupy — model serving, authentication, routing, client behavior, retries, and upstream provider availability.

For a legal team, the question is not whether GitHub’s incident record proves a particular legal vendor failed. It does not. The question is what the team does at 6 p.m. when an AI assistant used for research, drafting, summarizing, or citation checking is unavailable, intermittently degraded, or producing output that looks complete enough to trust. The answer should not live only in an IT ticket. It needs to live in the matter workflow: classify the failure state, switch the affected tasks to a manual path, and re-verify anything the tool touched during the degraded window before the work leaves the team.

Why the August 17 Copilot incident is the right case study

GitHub’s official status record placed the August 17 incident between 13:28 and 21:15 UTC, a 7-hour, 47-minute window. The same record reported peak error rates of about 20% for web and API requests and about 50% for archive and raw file downloads. Copilot was not the first component flagged; it was added at 14:31 UTC and was cleared last, after the surrounding platform components had already moved through mitigation and recovery stages.[1]

The post-mortem matters because it does not describe a simple “AI server down” event. GitHub attributed the outage to an Istio sidecar concurrency limit, misconfigured autoscaling, a cascade to four HAProxy nodes, and a latent Visual Studio Code retry bug that amplified Copilot Token Service traffic from roughly 7,000–9,000 requests per second to 70,000–100,000 requests per second. GitHub also wrote that monthly commits had grown from 1.4 billion in April to 2.9 billion, and said its remediation work included retry limits, retry budgets, and variable timeouts.[2]

That is the part a legal workflow should absorb. A tool can appear to sit on top of a stable platform and still remain impaired because the failing loop is somewhere else: a token service, a routing layer, a client retry pattern, an upstream model provider, or a component-specific backlog. If the firm’s policy says only “check the vendor status page,” it misses the period when the status page is improving but the assistant is still unreliable for the task in front of the lawyer.

Digital Applied’s independent timeline is useful for exactly that reason. It computed Copilot impairment at about 6 hours and 44 minutes, noted that Copilot was absent from GitHub’s 16:59 UTC mitigated-component list, and identified relapses after mitigation: Git Operations for 53 minutes, Issues for 2 hours and 46 minutes, and API Requests for 13 minutes. Its computed open-to-resolved incident duration was 7 hours and 36 minutes, which is not the same measurement as GitHub’s official 7-hour, 47-minute incident window.[3]

Those measurement differences should not be blended into one master outage number. They point to different facts: the vendor’s official incident window, an independent reconstruction of component behavior, and the practical user experience of a service that may recover, relapse, and recover again. For legal work, that distinction is more useful than a tidy duration.

For firms already tracking AI concentration risk after outages in other assistants, the ChatGPT outage concentration-risk analysis is the closest same-class analogue: the branded tool differs, but the operational question is the same — what happens to legal work when a convenience layer becomes a dependency.

Classify the failure signature before deciding what work can continue

The first operational mistake is treating every AI incident as “downtime.” Downtime is easy. If the assistant is plainly unavailable, lawyers know they must research, draft, and cite-check without it. The harder states are partial, client-specific, upstream, or relapsing failures — the states in which work can continue just long enough to create a false record of confidence.

A firm does not need a perfect technical diagnosis in the moment. It needs enough classification to route the work safely.

• Unavailable: the assistant cannot be reached, authentication fails, prompts do not submit, or the vendor status page confirms an outage. Work that depends on the assistant moves to the manual path.
• Degraded: the tool responds slowly, times out, produces intermittent errors, drops sessions, or works for some users and not others. Do not treat successful prompts as proof that all related output is reliable.
• Partial-output failure: the assistant returns some useful text but silently omits sources, skips issues, truncates analysis, or fails on a subset of requests. This is the highest-risk state for filing work because the draft can look normal.
• Client-specific failure: the web interface works but the desktop client, Word add-in, browser extension, IDE, or firm integration does not. The August 17 Copilot post-mortem is a reminder that retry behavior in a client can amplify a platform problem rather than merely reflect it.
• Upstream-provider failure: the legal tool’s interface remains available, but a model provider, embedding service, authentication provider, or retrieval layer is degraded. The wrapper is not always where the failure lives.
• Relapse after mitigation: the vendor reports mitigation or recovery, but specific components, users, or tasks fail again. This is why a legal workflow should require its own post-recovery verification rather than simply waiting for green status.

The June 4, 2026 Copilot code review incident shows why the partial-output category deserves its own label. GitHub reported that an average of 81.6% of Copilot code review requests failed, peaking at 93.9%, with about 36,800 requests affected. That was not merely an inconvenience; it was a failed assistance layer inside a review process, which is the closest software-development analogue to a legal team believing a machine has helped check work when it has not.[4]

A separate June 16, 2026 Copilot incident involved Opus 4.8 degradation by an upstream model provider. That fact is important for legal AI users because it shows the failure can sit below the branded product interface. The legal tool may be the screen the lawyer sees; the operative dependency may be somewhere deeper.[4]

This is also why the firm should keep an outage runbook separate from its normal AI-use instructions. A normal-state setup guide, such as a Copilot legal-workflows configuration with verification gates, tells lawyers how to use a tool when it is behaving. The outage runbook tells them when to stop trusting that behavior.

Apply a degrade-to-manual matrix by task, not by tool

The safest fallback is not “use another AI tool.” Sometimes that is appropriate. Sometimes it simply moves the same dependency problem to another wrapper. The better first move is to ask what legal task is underway and what consequence attaches if the assistant was wrong, incomplete, or unavailable.

The matrix should be attached to the matter plan before the deadline day. If it is invented during the incident, the person under the most time pressure will make the most legally consequential judgment with the least documentation.

How to tell whether your legal AI workflow was affected

Because no cited source documents a named legal AI vendor being directly disrupted by the August 17 Copilot outage, a firm should not tell lawyers that “legal AI went down” unless its own evidence supports that conclusion. The internal question is narrower: did the assistant used on this matter experience an unavailable, degraded, partial, client-specific, upstream, or relapsing state during the work window?

The answer usually comes from several records, not one dashboard.

1. Check the vendor’s status page and incident history, but record the exact service named. A platform-wide green indicator is less useful than a component record for drafting, research, authentication, document upload, retrieval, or model access.
2. Check firm logs: prompt timestamps, failed uploads, timeout messages, authentication errors, unusually long response times, missing source links, truncated answers, and repeated retries.
3. Separate web, desktop, add-in, mobile, and integrated-client behavior. If the web app worked but the Word add-in failed, classify the incident as client-specific for that matter.
4. Ask the vendor whether an upstream model provider, vector database, authentication provider, or routing layer was degraded. Do not accept “our app was available” as an answer to a dependency question.
5. Identify the degraded window for the matter from the first observed symptom to the last successful verification test, not only from the public incident start and end times.
6. Tag every draft, memo, summary, research trail, and citation check touched during that window for post-recovery review.

Frequency data can justify building this process, but it should not be used as if it proves a particular matter was affected. IncidentHub counted 257 GitHub incidents from May 2025 through April 2026, including 48 major incidents, 44 Copilot-specific outages with 9 major, and 10 Copilot incidents in February 2026 alone. It also categorized root causes across that period as including capacity, deployment, external dependencies, and configuration, among others.[5]

StatusGator records a separate Copilot outage duration of 9 hours and 56 minutes on August 3, 2026 and 6 hours and 45 minutes on August 17, 2026. Those numbers are useful as user-facing monitoring context, but they are not the same as GitHub’s official August 17 incident window or Digital Applied’s reconstruction.[6]

Post-recovery verification is not optional clean-up

Once the assistant appears healthy again, the legal risk becomes easy to underestimate. The team has a draft. The deadline is closer. The tool is green. This is exactly when degraded-window work product needs the most discipline.

The verification rule should be simple: any legal work product generated, edited, researched, summarized, cite-checked, translated, classified, or prioritized by the assistant during the degraded window is unverified until a human completes the applicable review. The issue is not whether the text reads well. It is whether the tool performed the task the team thinks it performed.

What the reviewer should re-check

• Authorities: confirm that every case, statute, regulation, rule, quotation, pincite, and parenthetical exists and supports the proposition for which it is used.
• Negative treatment and currency: rerun citator checks manually or in a trusted research system, especially if the assistant was asked to update or Shepardize authorities.
• Omitted issues: review the research plan to confirm the assistant did not silently skip a claim element, defense, jurisdictional rule, standard of review, remedy, or procedural deadline.
• Record citations: check all transcript, exhibit, declaration, deposition, contract, docket, and administrative-record references against the source documents.
• Summaries: compare AI summaries against the underlying documents before using them to make relevance, privilege, settlement, or strategy decisions.
• Confidentiality boundaries: confirm that no fallback tool or alternate workflow introduced client data into an unapproved system during the incident.
• Version history: identify which paragraphs, tables, research notes, or comments were created or changed during the degraded window, and preserve that record in the matter file.

The re-check must reach the final document, not merely the prompt history. Lawyers are already seeing courts and opposing parties focus on AI-generated legal errors, including fabricated citations. The Bianco ballot AI-citation record is a useful reminder of the consequence: the professional problem is not that a tool was used, but that unsupported legal material reached an adversary, court, or client.

A practical verification log can be short. It should identify the matter, tool, degraded window, affected work product, reviewer, sources checked, corrections made, and approving lawyer. If nothing changed after re-checking, say so. If sections were removed or rewritten, preserve that too. The point is not paperwork for its own sake; it is a record that the team recognized the degraded state and did not let AI-touched work pass through as if nothing had happened.

Close the supervision gap before the incident

The person who first notices the degraded assistant may be an associate, paralegal, litigation support analyst, contract attorney, or summer associate. The person who bears responsibility for the filing or client advice may be someone else. That gap is where an AI outage becomes more than a technology issue.

For U.S. legal teams, the outage SOP should sit beside the firm’s existing competence, supervision, confidentiality, and verification policies. If the firm uses ABA Formal Opinion 512 or state AI guidance in its training materials, the outage procedure should be mapped to those same duties without pretending that a bar opinion has created a special “Copilot outage” rule. The safer formulation is modest: when a lawyer uses an AI system in legal work, the lawyer still needs a reliable way to verify the output and supervise the people and processes that use it.

The firm’s AI acceptable-use policy should therefore say who can declare an assistant degraded, who notifies active matter teams, which tasks pause automatically, when partner approval is required, and what must be logged before filing or delivery. If the policy only says “verify AI output,” it leaves the hardest moment unresolved: how to verify output created when the tool was half-working.

Procurement should ask about dependency recovery, not just uptime

Legal-tech buyers should not turn the GitHub incident into a vendor accusation. They should turn it into a due-diligence script. Ask whether the legal AI vendor depends on one model provider or several; whether authentication, retrieval, document processing, and generation have separate status reporting; whether clients can see component-level incidents; whether retries are bounded; whether degraded output is labeled; and whether the vendor has tested relapse after mitigation.

The market is already moving around this issue. Bloomberg Law reported on August 19, 2026 that Harvey and Thomson Reuters were moving away from sole reliance on OpenAI and Anthropic, citing Harvey’s custom model “Tenet,” reportedly on Kimi K3, and Thomson Reuters’ own model “Thomson.” That reporting does not prove those vendors are immune to outages. It does show that dependency concentration is no longer a theoretical procurement concern.[7]

The same procurement frame applies below the model layer. A vendor may diversify model providers and still have a fragile document-ingestion path, retrieval index, authentication dependency, or add-in client. That is the lesson from failures below the visible interface, the same category discussed in AI infrastructure supply-chain strain and legal AI performance. Reliability review should ask where the service can degrade, not only whether the chatbot window opens.

For renewal and purchasing files, keep the vendor’s incident history with the same seriousness as security documentation. The questions belong with the broader legal-tech buyer record, including how financial and infrastructure pressure can affect AI vendors. A product that is excellent on ordinary days still needs a credible answer for degraded days.

The operating rule

Treat “AI assistant degraded or unavailable” as its own legal-work risk state. Do not collapse it into general IT downtime, and do not wait for a green status page to decide whether work product is safe. Classify the failure signature, move affected tasks to the manual path, log the degraded window, and re-verify AI-touched work before it is filed, sent, relied on, or used to make a client decision.

That rule does not require a firm to abandon legal AI. It requires the firm to stop treating an unreliable assistant as if it were merely slow.

References

1. Incident with Git Operations, Issues, API Requests, GitHub Copilot, Packages, Pages and Pull Requests — GitHub Status — August 17, 2026
2. The August 17 outage, and the work ahead — GitHub Blog — August 20, 2026
3. GitHub Outage: Copilot Dependency Chain, August 2026 — Digital Applied
4. GitHub Availability Report: June 2026 — GitHub Blog
5. GitHub Reliability & Outage History 2025–2026 — IncidentHub
6. GitHub Copilot Status History — StatusGator
7. Legal Tech AI Firms Shift Away From Anthropic, OpenAI Reliance — Bloomberg Law — August 19, 2026