TLDR:
- On 12 November 2026, a global Microsoft 365 outage knocked Outlook, Teams, Exchange Online, Copilot, SharePoint, Intune, Purview, and Defender XDR offline for roughly 10 hours, from about 17:54 UTC to 05:33 UTC the next morning.
- Downdetector peaked at about 130,000 Outlook reports around 1 pm ET
- Services recovered unevenly, and some admins could not reach the Microsoft 365 admin center to pull their own health information.
- Microsoft says this was not a cybersecurity breach; the stated cause, as of writing, is that a core process handling secure connections on affected servers became overwhelmed and failed automatic health checks, leaving the remaining servers to absorb the load.
After the July 2024 CrowdStrike fiasco, which took down an estimated 8.5 million Windows machines running Falcon and cost the global economy more than $10 billion by various insurer estimates, I had hoped the industry would collectively get religion about single points of failure in the Microsoft ecosystem.
Clearly it did not, because on 12 November 2026 we watched another global Microsoft event unfold, this time from the cloud side rather than an endpoint agent, and the dependency map it exposed looks eerily similar: millions of knowledge workers locked out of email, chat, meetings, file access and, critically, the security and compliance tooling they rely on to spot anything unusual going on in the background.
This was Microsoft’s own Exchange Online infrastructure falling over, but the business impact for anyone whose entire stack lives inside Microsoft 365 was broadly the same. Here is what I have pieced together from Microsoft’s status updates and independent reporting, and what I would do about it.
What happened #
The incident started at roughly 17:54 UTC on 12 November 2026 and was first acknowledged by Microsoft a few minutes before 1 pm ET on its Microsoft 365 Status account on X. Within about an hour, Downdetector reports of Outlook problems climbed to around 130,000, and users were seeing issues with Teams, Copilot and the wider Microsoft 365 suite. Microsoft logged the incident as EX1550543 and MO1550821.
Technically, this had the shape of a cascading health-check failure rather than a bad deploy. Early messages said Exchange Online servers had become unresponsive and were failing automatic service health checks, which pulled them from rotation and pushed their traffic onto the servers still passing checks. Those remaining servers then saturated and began failing their own checks, creating a feedback loop that chewed through capacity across the region.
A later update, timestamped around 01:06 UTC on 13 November, narrowed the fault to “a core process on affected servers” responsible for establishing secure connections, which lines up with why Outlook, Teams federated connections, Copilot and Graph-dependent services all degraded together: they share the authenticated front-end plane.
Microsoft’s mitigation followed the standard playbook for this failure mode. They “validated an alternative service health check method,” which in plain English means they relaxed the probe that decides whether a server is healthy so it stopped killing servers that were actually serving traffic.
Then they reintroduced servers gradually, warning that “servers can become unresponsive again once they receive traffic”, which is engineer-speak for “we have not fixed the underlying issue; we have found a way to keep the system up while we work on it.” Access was reported largely restored by about 05:33 UTC on 13 November, roughly 11 to 12 hours after the first reports. Microsoft publicly confirmed this was not a cybersecurity breach.
Every fortnight our security engineers update DAST vulnerability scanner’s test cases. So we’re always one step ahead.
Affected Products and Versions #
Based on Microsoft’s service health notices and incident updates on 12 to 13 November 2026, the following cloud services were reported degraded or unavailable during the window:
- Exchange Online, affecting Outlook on the web, classic Outlook desktop, new Outlook for Windows, Outlook for Mac, and Outlook mobile across tenants globally.
- Microsoft Teams, including chat, meetings and calling on Windows, macOS, web and mobile clients.
- Microsoft 365 Copilot, both the standalone Copilot experience and Copilot inside Word, Excel, PowerPoint, Outlook and Teams.
- SharePoint Online and OneDrive for Business file access through the web and the sync clients.
- Microsoft Intune device management, including policy delivery and admin console access.
- Microsoft Purview, including compliance, DLP, and information protection workflows.
- Microsoft Defender XDR, including the unified portal and parts of the incident, hunting, and response surface.
- The Microsoft 365 admin center itself, which showed issues on some pages, under incident MO1550821, which meant some administrators could not reach Microsoft’s own health information during the event.
On-premises Exchange Server, on-premises SharePoint Server, and other self-hosted Microsoft products were not affected by this incident, since the failure was inside Microsoft’s cloud infrastructure rather than in client software.
Downstream services that depend on Microsoft APIs, including OpenAI and Anthropic connectors, reported related errors during the window, which fits a Microsoft-side infrastructure failure rather than a client bug.
Why this matters from a security perspective #
Even a non-malicious outage has security consequences, and that is the part I want to flag for anyone writing an internal advisory.
First, several of the affected services are themselves part of the security stack. When Defender XDR and Purview are degraded, so are your detections, alerts, DLP enforcement and compliance workflows. An attacker with access to those tenants during the window would have been working against a blinded SOC.
Second, the admin center itself showed degradation, which means some administrators could not reach Microsoft’s own service health notifications to confirm what they were seeing. If your runbook starts with “log into the admin center and check incident status,” it broke here.
Third, the outage removed the primary communication path for exactly the people who most needed to communicate during an incident. If Outlook and Teams are your only channels for incident response, that is a single point of failure you have just watched fail.
Recommended actions #
This incident should be treated as an unplanned business continuity exercise rather than an isolated infrastructure event. The following actions address the dependency gaps and detection blind spots it exposed, and should be prioritised before Microsoft publishes its post-incident review.
- Capture the window locally : Pull sign-in logs, mail flow, and endpoint telemetry for roughly 17:00 UTC on 12 November to 06:00 UTC on 13 November from any systems that store them outside Microsoft, so you can review activity during the period when your Microsoft-native detections were unreliable.
- Stand up an out-of-band channel now : A pre-provisioned Signal, Slack, or secondary mail tenant for incident response costs almost nothing in quiet months and is invaluable when the primary channel is the incident.
- Watch for the preliminary post-incident review : Microsoft typically publishes one within 48 to 72 hours in the admin center under the same incident IDs (EX1550543 and MO1550821). Read it, map the failure mode to your own dependencies, and feed it into your next tabletop.
- Audit what else rides on Exchange Online and Entra ID : MFA prompts, SSO into third-party apps, ticketing, and on-call paging often lean on these quietly. An outage is the cheapest discovery tool you will ever get.
Final thoughts #
Microsoft will publish a root cause, and this outage will fade from the news cycle in a week. The dependency it exposed will not. If you only take one action from this advisory, make it the out-of-band channel, because the next outage will not wait until you have one, and if you take a second action, run the tabletop this outage already gave you for free.
Disclaimer: This advisory reflects what is known at the time of publishing. Microsoft has not yet released its preliminary post-incident review, so technical details and timelines may change. This post will be updated as more information becomes available.