Why Is My Copilot Not Working: The Hidden Account, Network, and Tenant Limits Behind Most Failures

Your Copilot is probably not working because the request never reaches the model. The failure sits earlier in the chain: a collapsed sign-in token, an inactive license assignment, a blocked endpoint, or a tenant policy that silently overrides the feature. Microsoft 365 Copilot, Windows Copilot, GitHub Copilot, and the consumer Copilot app each fail differently, so the fix depends on identifying which layer broke before you troubleshoot the model itself.

The request chain that decides success or failure

Every Copilot interaction passes through six layers in sequence. Identity proves who you are. Entitlement proves you paid for the feature. Policy decides what the tenant allows. Network transport moves the prompt to Microsoft. The orchestration service assembles grounding data and routes to a model. The model generates a response that flows back through the same layers.

A failure at any layer produces a symptom at the surface, and the symptoms overlap. A grayed-out button usually means entitlement or policy, not a model outage. A spinner that never resolves usually means network transport. A generic "something went wrong" message usually means the orchestration service rejected the request after identity succeeded.

The key mechanism is token expiry and refresh. Microsoft 365 apps hold short-lived access tokens, typically around one hour, refreshed silently in the background. When the refresh fails, the app keeps rendering the interface but every Copilot call returns an authentication error. The UI often hides this. You see a working chat box that produces nothing.

A second mechanism is licensing propagation. Assigning a Copilot license in the admin center does not activate it instantly. Entitlement claims propagate through the identity token, and stale tokens keep the old claims until they refresh. This is why a newly licensed user can wait hours and still see no Copilot, while a sign-out and sign-in fixes it immediately.

Plain language: most Copilot failures are plumbing problems, not intelligence problems.

Where failures actually cluster, by product and rate

The four major Copilot products fail at different rates for different reasons. Matching your symptom to the product narrows the diagnosis fast.

Microsoft 365 Copilot failures concentrate in tenant configuration. Administrative policies, sensitivity label restrictions, and Conditional Access rules block Copilot for subsets of users while leaving others untouched. The same tenant can show Copilot working for one department and dead for another. That pattern almost always indicates policy scoping, not an outage.

GitHub Copilot failures concentrate in editor integration and subscription state. A lapsed individual subscription, an expired organization seat, or a proxy that blocks the extension's endpoints each produce near-identical symptoms: no completions, no chat, no error detail.

Windows Copilot failures concentrate in regional availability and OS build. The feature shipped progressively by market and by Windows version, so a machine that never received the enabling update shows no Copilot at all rather than a broken one.

Consumer Copilot app failures concentrate in account state and network filtering. Signed-out sessions, region locks, and DNS-level blocking dominate.

One counterintuitive detail: reinstalling the app rarely fixes anything. The failure almost always lives in identity, policy, or network, and a reinstall preserves all three. Technicians who reinstall first usually waste the most time.

Edge cases that mimic outages but are not

Some failures look like Microsoft-side outages and are not. Recognizing them prevents hours of pointless waiting.

Conditional Access policies that require compliant devices will block Copilot on personal machines while leaving corporate laptops working. The user sees a broken feature; the tenant sees a correctly enforced policy.

Sensitivity label inheritance blocks Copilot from files whose labels restrict processing. Copilot refuses to ground on content it is not permitted to read. The user experiences this as Copilot "not finding" documents that plainly exist.

Proxy and TLS inspection appliances break Copilot in a specific way: the connection establishes, then the orchestration call fails because the appliance rewrites or blocks a required endpoint. Browsers may work while the desktop app fails, because they use different proxy paths.

Region and data-residency settings can disable Copilot for users whose mailbox or files live in an unsupported geography, even when the license is active.

Red flag: Copilot fails for every user in one office but works remotely — suspect network egress or proxy. Red flag: Copilot fails for one department only — suspect policy scoping or license group membership. Red flag: Copilot worked yesterday with no admin change — suspect token refresh, service health, or a client update. Red flag: Copilot chat works but file grounding returns nothing — suspect permissions or sensitivity labels, not the model. Red flag: Errors appear only in the desktop app, never in the browser — suspect the client install or its proxy configuration.

Timeline: how a typical Copilot failure unfolds and resolves

Timing separates transient failures from configuration failures. The table below maps the common course of each failure type.

The practical value of this table is triage speed. If your failure has lasted under an hour and a re-login fixes it, you never needed to open a support ticket. If it has lasted days and affects a defined group, no amount of retrying will help.

Comparison: which Copilot, which likely cause, which first check

The pattern across all five rows: the first check is never "is the model down." It is always identity, entitlement, or transport.

Misconceptions that send troubleshooting in the wrong direction

The most expensive misconception is that Copilot failures are model failures. They almost never are. The model is the last link in a six-link chain, and the first five links fail far more often.

A second misconception is that a working chat interface proves the backend is reachable. The interface renders locally. It can render perfectly while every request behind it fails authentication.

A third is that admin changes take effect immediately. License and policy changes propagate through token refresh cycles, so the correct test is a fresh sign-in, not a page reload.

A fourth is that a status page showing green means your Copilot should work. Status pages report service-wide health, not tenant policy state, not per-user entitlement, and not client configuration.

Professional caveat: in large tenants, the same visible symptom can have three different causes across three user groups. Diagnose per group, not per tenant. A single "Copilot is broken" report from one user tells you almost nothing about the organization.

Practical actions with concrete thresholds

Work through these in order. Stop when the symptom clears.

Step 1: Force a fresh identity token. Sign out completely, close all Microsoft apps, and sign back in. This clears the most common cause and takes under two minutes. If Copilot returns, you are done.

Step 2: Verify entitlement. Confirm the license is assigned to the user, not merely purchased. In Microsoft 365, check group-based licensing membership. Entitlement changes can take up to 24 hours to propagate, so re-test after a fresh sign-in rather than repeatedly reloading.

Step 3: Test a second client. Open Copilot in a browser and in the desktop app. If one works and the other fails, the problem is client-side configuration, not the service. This single test eliminates half the possible causes.

Step 4: Check tenant policy. Confirm Conditional Access rules, sensitivity label restrictions, and Copilot-specific policies do not exclude the affected users. Compare a working user and a failing user in the same tenant. The difference between them is your cause.

Step 5: Check network path. Confirm the required endpoints are reachable and not TLS-inspected in a way that breaks the connection. Test from a network outside the corporate proxy. If Copilot works off-network, the proxy is the cause.

Step 6: Confirm service health and version eligibility. Check the vendor status page for active incidents. Confirm the OS build or app version meets the minimum for your region. An ineligible build or region produces absence, not errors, so verify eligibility before assuming breakage.

Thresholds worth remembering: under one hour and fixed by re-login means token. Under 24 hours and fixed after license assignment means propagation. Persistent and group-specific means policy. Persistent and site-specific means network.

Limits of what this diagnosis can establish

This framework identifies the layer of failure, not the exact misconfigured rule. Tenant policy interactions can be complex enough that only an administrator with full audit access can pinpoint the blocking rule. Vendor-side incidents can only be confirmed against the official status page.

Client logs vary by product and version, and their formats change. Treat log contents as clues, not verdicts. When the layer is identified but the specific cause is not, escalate to your administrator with the layer, the affected user group, and the timing pattern. That triage shortens resolution more than any single fix.

Finally, availability, pricing, licensing terms, and regional rollout of Copilot products change frequently. Confirm current eligibility and entitlement details with the vendor's official documentation before acting on them; this article explains stable mechanisms rather than dated specifics.