Copilot usually stops working because the request never reaches the model or the model's reply never reaches your editor. That breaks into five root causes: expired authentication tokens, network or proxy interception, service-side throttling, extension state corruption, or account and license mismatches. Each produces a different symptom pattern, which is why "it's broken" rarely maps to one fix.
Most troubleshooting guides treat Copilot as a black box and tell you to reinstall it. That works occasionally because reinstalling clears cached credentials. But reinstalling also destroys the diagnostic evidence you need. Understanding the request path first turns a random walk into a short, ordered checklist.
The request path and where it breaks
Every Copilot interaction is a chain of five hops. Your editor extension captures context, authenticates through a token service, sends a prompt to a completion endpoint, receives a streamed response, and renders it inline. A failure in any hop looks identical to the user: nothing appears, or an error toast flashes once.
Authentication is the most common break point. Copilot uses short-lived access tokens refreshed by a longer-lived credential stored in your OS keychain or credential manager. If the refresh fails silently, for example because the keychain is locked or the clock is skewed, the extension keeps sending requests that the server rejects with a 401. Many extension versions retry quietly, so you see a spinner that never resolves rather than an error.
Network interception is the second. Corporate TLS inspection, VPN split tunneling, and aggressive firewall rules can terminate the connection before the completion endpoint responds. The extension may fall back to a status check that succeeds while completions fail, which is why the Copilot icon can look healthy while suggestions never appear. This split between "signed in" and "can complete" is the single most useful diagnostic distinction.
The streaming layer adds a third failure mode. Completions arrive as server-sent events, a long-lived HTTP stream. Proxies that buffer responses will hold the stream until it closes, so the suggestion arrives all at once, late, or times out entirely. A proxy that works fine for ordinary web browsing can still break streaming.
What the numbers reveal about where time goes
Latency budgets explain most "slow or dead" complaints better than error codes. A completion request typically involves 100 to 300 milliseconds of network round-trip, plus model time-to-first-token that ranges from roughly 200 milliseconds to over 2 seconds depending on model size and load. Add editor-side context gathering, and anything above about 2 to 3 seconds feels broken to a user typing continuously.
Throttling thresholds matter too. Rate limits are usually expressed as requests per minute and tokens per minute, and they differ by plan tier. Hitting a requests-per-minute ceiling produces 429 responses that the extension may swallow. Hitting a token-per-minute ceiling can fail only the largest requests, so small completions work while chat or long-context features fail. That asymmetry is a strong clue: if short suggestions work but chat dies, suspect token limits or context size, not connectivity.
Clock skew deserves a number. Token validation commonly tolerates only a few minutes of drift. A system clock off by more than about 5 minutes can cause every refresh to fail even though credentials are valid. Virtual machines restored from snapshots and dual-boot systems are the usual culprits.
Timeline of a typical failure
| Stage | What happens | Typical symptom | Time to appear |
|---|---|---|---|
| Token refresh | Cached credential fails to renew | Spinner, no error | Immediate |
| Auth rejection | Server returns 401 to requests | Silent retry loop | Seconds |
| Network interception | TLS or proxy blocks endpoint | Suggestions never arrive | Immediate |
| Stream buffering | Proxy holds response open | Late or partial output | 5 to 30 seconds |
| Rate limiting | 429 from requests or token cap | Intermittent failures | Minutes |
| Extension state | Corrupted cache or stale version | Persistent failure after reinstall | Until cleared |
| Service incident | Upstream outage | All users affected | Varies |
The ordering matters. Service incidents affect everyone at once, so checking a status page first saves time. Everything below the incident row is local and reproducible.
Edge cases that mimic outages
A license mismatch is the most misdiagnosed case. If you sign into the editor with one account and Copilot with another, the extension may show as active while completions fail authorization. This happens frequently on machines with personal and work profiles, and on shared lab computers where credentials persist across users.
Language and file-type gating causes confusing partial failures. Copilot may be disabled for certain file types, for very large files, or when the editor cannot determine the language. The result is a tool that "works" in one project and appears dead in another. Similarly, unsaved buffers and files above a size threshold can be excluded from context, so suggestions degrade rather than disappear.
A counterintuitive detail: the Copilot status icon is a poor health signal. It reflects authentication state, not completion reachability. A green icon with no suggestions is the classic signature of a network or streaming failure, not an account problem. Professionals learn to test a chat request and a code completion separately, because they exercise different endpoints and different rate limits.
Red flag: suggestions stopped after a password change or MFA re-enrollment. Red flag: failures began after joining a VPN or changing DNS settings. Red flag: only large files or chat fail while short completions work. Red flag: the editor was updated but the extension was not. Red flag: multiple users on the same network fail simultaneously.
Misconceptions about why Copilot fails
The most common misconception is that reinstalling is a diagnostic step. It is a reset, and it erases logs and cached state that identify the cause. Clear the extension's cached credentials and check the editor's output or log panel before reinstalling.
A second misconception is that a working internet connection means Copilot should work. Copilot needs specific endpoints reachable over a streaming connection with valid TLS. A network that passes a browser speed test can still block the completion endpoint or buffer its responses. Test the specific host, not the internet in general.
A third is that failures are always server-side. Service incidents are real but comparatively rare per user. Most individual failures are local: token, clock, proxy, extension version, or license. Check the status page to rule out the incident, then work the local chain.
Finally, people assume the extension updates with the editor. They are versioned separately. An editor update can leave an older extension calling a deprecated endpoint, producing failures that look like outages but resolve with an extension update.
Practical actions and thresholds
Work the chain in order. Each step isolates one hop and takes under two minutes.
Check the provider status page for an active incident. If one exists, stop; local fixes will not help. Verify your system clock is within about 5 minutes of true time, then sign out and back in to force a token refresh. Open the editor's output or log panel for the Copilot channel and look for 401, 403, 429, or timeout entries. The code tells you which hop failed. Test a short code completion and a chat request separately. Short-only success points to token limits or context size; total failure points to auth or network. Switch off VPN and any TLS-inspecting proxy for one test. If completions return, the network path is the cause. Confirm the extension version matches your editor version, and update if not. Clear cached credentials, then reinstall only if the log shows persistent local corruption.
For thresholds, treat any completion above about 3 seconds as degraded and any repeated 429 within a minute as rate limiting. If a 401 persists after a forced re-authentication and a clock check, suspect a license mismatch between editor and Copilot accounts rather than a service outage.
Limitations and what logs cannot tell you
Local logs show which hop returned an error, but they rarely show why a proxy buffered a stream or why a server throttled a specific account. Server-side decisions are opaque by design. Diagnostics also cannot distinguish a per-account throttle from a per-organization policy without administrator access.
One professional caveat: if you are on a managed device, many of the fixes above are blocked by policy, and the correct action is a ticket to your IT team with the log excerpt and timestamp. Changing proxy or certificate settings on a managed machine can violate policy. Reproduce the failure, capture the error code, and escalate.
The honest limit is this: for a single user, the chain above resolves most cases, but root cause for intermittent throttling often requires the provider's own telemetry. When local diagnostics come up clean and failures persist across networks and accounts, the remaining explanation is service-side, and waiting or escalating is the correct response.