Multi-day Exchange Online outage hits Outlook, Copilot and Purview with no root cause

A Microsoft 365 incident that began on 12 November 2026 remained unresolved as of 14 November, with incidents EX1550543 and MO1550821 still open and no root cause published, according to a write-up by teamvoy on dev.to. The failure originated in Exchange Online, but its effects reached well past email: Copilot, Defender for Office 365, Purview DLP and eDiscovery, Planner, To Do, parts of the admin center and Teams calendar functions all degraded alongside mail.

One dependency, many symptoms

The connecting thread, as the dev.to timeline explains, is that every one of those services reads from Exchange Online. That is why mail delivery could stall while Teams group chats kept working in the same hour, yet calendar invites and contact lookups — which touch Exchange — failed. Outlook on the web, desktop and mobile connections (MAPI, ActiveSync, REST) all lost access, and Microsoft Graph requests involving mail, calendar or contacts were affected. Teams calls, meetings and channel messages, plus files stored directly in SharePoint Online, largely kept running because they do not depend on Exchange.

Four explanations in two days

Microsoft's public account shifted four times during the incident, and the sequence matters more than any single statement:

• First it cited elevated load across multiple regions, then clarified that the pressure came from servers going unavailable — capacity disappearing under ordinary demand rather than a traffic surge.
• It then said servers were failing automated health checks, possibly because of a component that processes them, and froze deployments and configuration changes while investigating.
• Next came word that a process establishing secure connections was overwhelmed on the remaining servers, knocking them out of the request path too.
• Finally it identified a recent network configuration change that lines up with the start of impact and began rolling it back overnight.

That last statement reverses an earlier one: at 19:57 UTC on 12 November, Microsoft had said no recent change correlated with the onset. The root-cause field on the incident remains blank, and a correlation is not a confirmed cause. Microsoft has also said repeatedly that it is not aware of malicious activity — a statement about its current knowledge, not a closed finding.

How the incident unfolded

The day actually began with a separate Teams incident, TM1550488, which affected users in the Americas from 14:45 to 15:53 UTC with delayed chats and presence issues, preliminarily blamed on resource contention. It closed before the Exchange trouble started, and Microsoft has not linked the two — though, per dev.to, much coverage merged them.

At 16:17 UTC, EX1550543 opened as users lost access to Exchange Online mailboxes. Microsoft redistributed connection traffic, paused deployments and restarted servers by roughly 19:00, and an alternative health check brought a subset of servers back around 21:00. At 22:11 the company conceded its actions had not delivered the expected relief, and recovered servers went unresponsive again that evening under load. Recovery continued into 13 November: frontend servers were still being restored at 06:12 UTC, and by 12:30 Microsoft reported progress while warning that intermittent problems could persist.

Counting the damage carefully

Two caveats from the write-up deserve repeating. The "450 million users" figure circulating in coverage is Microsoft's overall user base, not a count of affected customers, and Downdetector's roughly 130,000 Outlook reports are user reports, not confirmed outages. Delayed mail was protected by a 48-hour retry window, so administrators are advised to check for late arrivals rather than assume messages were lost. The consequences were sharpest where email is a control rather than a convenience: a public company postponed an earnings release, and a county sheriff's office reverted to taking bond payments in person.

What to watch

Microsoft's service description promises a preliminary report within 48 hours of resolution and a final report within five business days for incidents affecting many organizations — stated policy, not a prediction for this case. The dev.to write-up flags three open questions: whether the reverted network change was the initiating defect or a coincidence; why automated health checks removed capacity faster than recovery could restore it; and what will change in deployment pausing and traffic shaping as a result.

Why it matters

The incident is a live demonstration of hidden coupling inside a flagship SaaS suite: security tooling, compliance pipelines and meeting scheduling all sat downstream of a single mail platform, and many organizations apparently did not know it. The write-up's practical lessons are to map dependencies before buying redundancy, to give status communications, paging and regulatory notifications a path that does not depend on Exchange, and to design workflows so email notifications degrade gracefully while email-gated processes fail loudly and route to a human. It also notes that Microsoft's own recovery was unstable — servers that returned dropped out again — which makes rehearsing a long Exchange degradation, including the reconciliation work afterward, a sensible exercise for any tenant.