Microsoft 365 Copilot went down with the mail server — and that is the whole argument about integrated AI assistants
Update, 5 September 2026: Two days later the same lesson arrived without a single named dependency: four AI providers degraded inside one morning with no shared cause published, which is the harder version of this problem to design against.
TL;DR: At 17:30 UTC on 31 August 2026 Microsoft logged incident EX1464935 against Exchange Online. It widened into MO1465074, taking in Teams, SharePoint, OneDrive, Purview, Defender XDR, the Microsoft 365 Admin Center, Universal Print — and Microsoft 365 Copilot. The stated cause was not load and not an attack: “an issue within a core authentication configuration used by multiple Microsoft 365 services.” Recovery took more than a day; on the morning of 2 September Microsoft was still deploying fixes, concentrating on REST and Graph API connection paths. The AI-specific line in the advisory: “Users’ Copilot prompts that require Microsoft 365 grounding, such as email content, may fail.” Why it matters: grounding in your own tenant is the entire reason an integrated assistant costs more than a free chatbot — and grounding is precisely what an identity-layer failure removes, while leaving the assistant articulate enough to look fine. For you: map each AI feature to the identity system it depends on, keep one fallback that authenticates somewhere else, and make retrieval failures raise loudly instead of returning nothing.
What happened
The incident started as an email problem. Microsoft’s admin centre logged EX1464935 at around 17:30 UTC on 31 August 2026, covering Exchange Online: mail delayed or failing to send, mailbox search returning nothing, authentication errors on mailbox operations. Downdetector took over 6,000 Outlook reports that day.
Within hours it was no longer an email problem. Microsoft opened the broader MO1465074, and the affected-services list read like an inventory of the working day: OneDrive for Business, SharePoint Online, Microsoft Teams, Microsoft Purview, Microsoft Defender XDR, the Microsoft 365 Admin Center, Universal Print and Microsoft 365 Copilot. Teams users saw calendar and search failures, stale presence, and Teams Rooms devices reporting themselves offline to administrators.
The cause Microsoft gave was a single sentence, and it explains the spread:
“An issue within a core authentication configuration used by multiple Microsoft 365 services is resulting in impact.”
A misconfiguration had stopped authentication components deploying as expected to part of the infrastructure. Engineers resorted to manual server-level resets. Roughly 22 hours after the first acknowledgement Microsoft reported “positive recovery trends,” and mail flow and search came back on 1 September. By 09:07 on 2 September the company said availability was “stable above 99 percent” and that most users should no longer see impact, with remaining work aimed at REST and Graph API connection methods. The advisory was still open.
None of that is remarkable. Large suites have bad days, and an identity-layer config error is among the most ordinary ways to have one. What makes this a story for AI buyers rather than for IT admins is one line Microsoft wrote about Copilot.
The line that matters
“Users’ Copilot prompts that require Microsoft 365 grounding, such as email content, may fail.”
Read that as a product description in reverse. Grounding — the assistant’s authorised access to your mail, your files, your calendar, your Teams history — is the whole of the value proposition. Strip it out and Microsoft 365 Copilot is a competent general-purpose chatbot, which is a thing you can get from ChatGPT, Claude or Gemini at consumer prices or for nothing. The per-seat premium buys the grounding. And the grounding is the part that runs through the authentication plane that broke.
So Copilot’s failure during this outage was not a crash. It was a quality collapse that preserved fluency. The model was never down. Ask it to rewrite a pasted paragraph and it performed exactly as always. Ask it what was in this morning’s thread from the client, and it could not reach the mailbox. An assistant that has lost its context does not usually announce that it has lost its context; it answers from what it has.
That asymmetry is why “degraded” is a misleading word here. In a suite where the visible failures are red — mail not sending, Teams showing you offline — the AI failure is the quiet one.
Integration is a dependency graph, and you bought all of it
The pitch for an embedded assistant is that it already knows things. That is genuinely valuable and it is why Microsoft’s agent strategy is built around tenant-native identity in the first place. But “it already knows things” is a compressed way of saying “it authenticates into six services that authenticate into one identity configuration.”
The counter-example is sitting in the same brand. GitHub Copilot was not on the affected-services list, because the coding assistant does not depend on Exchange Online’s authentication path. Same vendor, same product name, completely different exposure — decided entirely by what each one is grounded in. If you want to know how a given AI feature will behave in an outage, the vendor’s logo tells you almost nothing and the data dependency tells you almost everything.
This is the same structural point that showed up when GitHub’s own outage stranded agentic coding workflows in August: the more thoroughly an AI tool is woven into a platform, the more completely it shares that platform’s failure modes. Integration and blast radius are two descriptions of the same wiring.
There is a security-shaped version of the same observation, too. The Copilot connector research we covered in the CoSnitch memory-poisoning disclosure made the point from the opposite direction: the connectors that let an assistant read your tenant are also the surface through which it can be fed things you did not write. Availability and integrity are the same attack surface viewed from two angles, and both scale with how much you connected.
What the contracts actually promise
The reflex after an outage is to check the SLA. Do it, but expect less than you remember agreeing to.
Microsoft 365 carries a financially backed availability commitment on core services, and the remedy is a service credit — a percentage of the monthly fee for the affected service. For a two-day disruption to a knowledge-work suite, that is compensation measured against your licence cost, not against your lost day. It is not designed to make you whole and does not claim to be.
For AI features specifically the ground is softer. Assistant and agent capabilities are routinely newer than the SLA text that surrounds them, frequently in preview, and often explicitly carved out. This is an industry pattern rather than a Microsoft one: Anthropic withdrew its Priority Tier from sale in August — the only tier it offered with a published uptime target — which left the frontier-model market with essentially no consumer-visible uptime guarantee at all.
The honest planning assumption for any AI feature, from any vendor, is best-effort unless your contract says otherwise in writing. That is not cynicism; it is what the documents say.
What to do about it
Four things, none of them dramatic.
1. Write down the grounding, not the vendor. For each AI feature you depend on, note the data it needs and the identity system that authorises the access. Then check how many of your tools collapse onto the same row. Most teams find that a suite assistant, a meeting-notes tool, a search bot and three automations all terminate at one identity provider — which is why an outage that ought to hit one product hits five.
2. Keep one fallback outside the tenant. For any workflow where a stall costs real money, have a path that authenticates somewhere else. A second general assistant on another provider covers the drafting and reasoning half; the grounded half you cover with a documented manual procedure. Our productivity tools shortlist and the chatbot comparison are both usable starting points, and the practical test is simply whether the fallback works when your primary identity provider does not.
3. Make silent retrieval failures loud. This is the cheapest fix on the list and the most valuable. If you have built anything on top of a grounded assistant — a scheduled summary, an agent that files tickets, a retrieval step in an internal chatbot — check what it does when retrieval returns nothing. Written naively, it will produce a confident answer from an empty context and hand it downstream. Make the empty result raise an error. A workflow that stops is a nuisance; a workflow that invents is a liability.
4. Read the post-incident report against your own list. Microsoft typically publishes one to affected tenants. Its value is not the narrative but the mapping: which of your workflows failed, which failed loudly, and which you only discovered had failed afterwards.
The bottom line
Microsoft had a bad two days with a config change in the identity layer, and it will have fixed it before most readers of this page notice the advisory closed. The durable part is the sentence about Copilot grounding, because it is a precise, vendor-authored statement of what an integrated AI assistant actually is: a model you could get anywhere, plus authorised access to your own data, where the second half is both the product and the fragility.
Buy the integration — it is worth buying. Just hold it as what it is. The assistant is only as available as the least available thing it is grounded in, and unlike a mail server, it will not look broken while it is.
Sources
- Microsoft 365 Service Health advisory MO1465074 (incident text and updates through 2 September 2026), as reproduced by NHSmail Support
- BleepingComputer, Massive Microsoft 365 outage causes auth issues, service failures
- TechCrunch, Microsoft 365 outage drags on, but things are improving and Microsoft tests fix for latest hours-long Outlook outage
- TechDogs, Microsoft 365 outage enters second day as Outlook mail recovers, Teams and Copilot issues persist
Update, 3 September 2026 — the lesson here just acquired a much higher-stakes venue. On 1 September OpenAI announced that healthcare organisations can connect their Epic environments to ChatGPT for Healthcare, giving clinicians read-only access to appointment notes, lab results, medications and specialist documentation in a system holding records for more than 325 million patients. Launch partners include Cedars-Sinai, HCA Healthcare, Memorial Sloan Kettering and UCSF Health. That is the same architecture this article dissected — a capable model whose entire usefulness depends on a live authenticated pipe into a system of record — deployed where the cost of an unavailable connector is a clinician mid-shift rather than an inbox. The two questions this outage should make every buyer ask now apply to a clinical workflow: what does the assistant do when the connector is down, and does it say so rather than quietly answering from parametric memory? Why “read-only” is the strategy, not a caveat.
Frequently asked questions
Was GitHub Copilot affected by this outage?
No, and the distinction is worth holding onto because the two products share a brand and almost nothing else. The incident Microsoft tracked as MO1465074 was scoped to Microsoft 365 services authenticating against Exchange Online infrastructure — Outlook, Teams, SharePoint, OneDrive, Purview, Defender XDR, the Admin Center, Universal Print and Microsoft 365 Copilot. GitHub Copilot, the coding assistant, does not sit behind that authentication path and was not on Microsoft's affected-services list for this incident. That is a useful illustration of the argument in this article rather than a footnote to it: GitHub Copilot survived because it is not grounded in your Microsoft 365 tenant, and Microsoft 365 Copilot broke because it is. The dependency is the feature and the dependency is the risk, and which side of that trade you are on is decided per product, not per vendor.
Did Copilot stop working entirely, or just partially?
Partially, and the shape of the partial failure is the interesting part. Microsoft's advisory language was specific: 'Users' Copilot prompts that require Microsoft 365 grounding, such as email content, may fail.' A prompt that needs nothing from your tenant — summarise this pasted text, draft a paragraph, explain this concept — was running on a model that was never down. A prompt that needed to read your mailbox, search your SharePoint documents or check your calendar was hitting the authentication path that had broken. So Copilot degraded into something close to a generic chatbot: still articulate, no longer informed about you. For a licence bought specifically because it can see your organisation's data, that is the failure mode that costs you something, and it is easy to miss in a status dashboard that shows the service as merely 'degraded' rather than down.
What actually broke, and should I expect Microsoft to publish more?
Microsoft's stated preliminary cause was 'an issue within a core authentication configuration used by multiple Microsoft 365 services,' with a misconfiguration preventing authentication components from deploying as expected to a portion of infrastructure. Engineers performed manual server-level resets, and by the morning of 2 September the remaining work was focused on REST and Graph API connection methods. That is a plausible and unglamorous root cause — a config change in the identity path, which is the single most load-bearing and least visible layer in a productivity suite. Microsoft normally publishes a post-incident report to affected tenants in the Service Health dashboard within a few weeks, and for an incident of this length it is reasonable to expect one. If you run a tenant, the useful move is to retrieve that report when it lands and read it against your own dependency list rather than as trivia — specifically, to note how many of your automated workflows failed silently versus surfaced an error.
Does this mean I should not buy Microsoft 365 Copilot?
It does not, and treating a two-day incident as a verdict on a product would be the wrong lesson. Every cloud suite has authentication outages; Google Workspace and its Gemini integration share the same structural exposure, and a standalone assistant simply relocates the dependency to a different provider rather than removing it. What this incident should change is not the purchase but the plan around it. If Copilot is embedded in a workflow where a stall costs real money — customer response times, a compliance clock, a nightly summarisation job that feeds a report — then you need a path that does not authenticate through the same tenant. That can be as small as a documented manual fallback or a second assistant on a different provider. The mistake is not buying an integrated assistant; it is quietly making an integrated assistant load-bearing without noticing that it inherits every dependency of its host.
How do I work out my own blast radius before the next one?
Start from the grounding, not the vendor. For each AI feature you rely on, write down what data it needs and which identity system authorises that access, then ask what happens to the workflow when that authorisation path is unavailable for a full working day. Most teams discover two things. First, that several nominally independent tools collapse to the same identity provider, so an outage that looks like it should hit one product hits five. Second, that the automations built on top — an agent that files tickets, a scheduled summary, a retrieval step in an internal chatbot — fail quietly rather than loudly, because they were written for a service that returns data or errors, not one that returns empty results. Fixing the second problem is cheap and worth doing regardless: make retrieval failures raise, not return nothing, so a degraded assistant cannot silently produce confident output based on no context at all.
Is a status page a substitute for an uptime guarantee?
No, and the gap between the two is where most buyers get caught. A status page is a description of what is happening; a service level agreement is a commitment with a remedy attached, and for most AI features the second does not exist in the form buyers assume. Microsoft 365 carries a financially backed SLA on core services, but the remedy is a service credit, which is compensation on the order of a fraction of a monthly licence fee rather than anything resembling the cost of a stalled workday. On the AI side the picture is thinner still: assistant and agent features are frequently carved out of uptime commitments, and Anthropic went as far as withdrawing its Priority Tier — the only Anthropic tier with a published uptime target — from sale entirely. The practical posture is to treat every AI feature as best-effort unless a contract says otherwise in writing, and to size your dependence accordingly.
Sources
- Microsoft 365 Service Health advisory MO1465074, reproduced by NHSmail Support (updates through 2 September 2026)
- BleepingComputer — Massive Microsoft 365 outage causes auth issues, service failures
- TechCrunch — Microsoft 365 outage drags on, but things are improving (1 September 2026)
- TechCrunch — Microsoft tests fix for latest hours-long Outlook outage (31 August 2026)
- TechDogs — Microsoft 365 outage enters second day as Outlook mail recovers, Teams and Copilot issues persist
Related tool reviews
Questions or corrections? Email Pick Right. Want the full list? See all news.