The Microsoft 365 outage: one failed health check took down Outlook, Teams and Copilot
One component inside Microsoft's own health checks pulled healthy servers out of rotation, and Outlook, Teams and Copilot went with them for roughly 18 hours. The Microsoft 365 outage of November 12 was not an attack: a monitoring mechanism turned against the infrastructure it was watching.
What happened: 18 hours of downtime
The Microsoft 365 outage began on Thursday, November 12, 2026, around 13:00 ET, 18:00 GMT, and the major impact ran for close to 18 hours. The first notice described users unable to reach Exchange Online mailboxes through multiple connection methods in the Americas, tracked as incident EX1550543 in the admin center; the broader event was followed as MO1550821.
What looked like a regional problem escalated fast: within hours there were reports from 74 countries and territories, according to Downdetector's count, which measures user reports rather than affected users. The US peak topped 130,000 Outlook reports early on. Hospitals, GP practices, schools and police stations in the UK reported disruptions; airlines in India, including IndiGo and Akasa, hit operational issues tied to email.
At 23:04 GMT Microsoft said it was returning some affected servers to service. Restarts did not hold: machines rejoined, failed again and dropped out once more. By Friday the 13th service was restored in most regions, with intermittent problems afterwards.
Read also
Why one health check can take down 19 services
A health check is the question a load balancer asks every server: are you there and can you answer? If the answer fails, the server leaves the rotation. It is a safety feature that keeps traffic away from a broken machine. On November 12 that feature started answering wrong.
The loop: pulling servers raises load on the rest
When a check fails because of an internal component rather than a dead server, removal becomes a punishment. Every server that leaves adds work to the ones still in; more load means slower checks and more timeouts, and more timeouts mean more removals. That loop explains how a single failure grew from one service to nineteen, and why restarting changed nothing: the server came back healthy and the same component pushed it out again.
What "unexpectedly unavailable" means in Microsoft's own words
According to Microsoft, servers ended up "unexpectedly unavailable" under elevated load, and its investigation pointed to a specific component on those machines, the one responsible for processing the health checks. The company said it had not identified any recent changes correlating with the start of impact, and ruled out malicious activity: it described a technical issue unrelated to cyber or AI agents. The post-incident report was still unpublished, so the root cause is not closed: what exists is an official hypothesis under investigation.
The dependency chain: from Exchange to Copilot
Exchange Online is not just email. It is the identity and calendar layer that Teams, SharePoint, OneDrive, Planner, To Do, Defender XDR, Word and Excel on the web, and Microsoft 365 Copilot all sit on. The count of 19 affected services comes from a press analysis, not from a total published by Microsoft: the company gave a list of affected services, without a global figure.
When mail goes down, the calendar loses its base, Teams meetings lose the invite, Planner stops notifying and the assistant that drafts your replies loses context. It is the same pattern as the global Salesforce outage in September: look at the whole chain, not the visible symptom.
The most uncomfortable detail: the Microsoft 365 connectors used by outside tools, including OpenAI's and Anthropic's, failed too. A mail failure now reaches the assistant that reads your calendar, because that assistant goes in through the same connector.
What the teams that kept working did differently
They had no magic fix: they had an alternate path already tested. A communication channel outside Microsoft 365 — a messaging group, a mailing list on another domain, an on-call phone — is the first thing you need when the status page is slow. Offline mode covers documents and already-synced mail, not what arrives during the outage. And one source of truth stops five people from asking the same question in five channels.
Once service is back, the admin work starts: read the service level agreement, calculate the real downtime window from the official updates and request the post-incident report. Credits rarely cover the loss; the report does help, because it says which components failed and what changed at the provider.
What to check in your own stack
The Microsoft 365 outage is a warning that travels well beyond Microsoft. Any system with a load balancer and health checks has the same blind spot.
First, list what breaks if your mail provider disappears for two hours: the login that emails a link, notifications, billing, the assistant that reads your calendar. Then check which fallback actually exists and when it was last exercised; a fallback nobody has run is an intention. Second, check your health checks: that their failure does not depend on a shared resource that also saturates under load, and that the removal threshold tolerates retries before pulling a node. An aggressive check against a slow backend empties the pool exactly when you need it most.
Conclusion
The Microsoft 365 outage was not caused by an attacker or a faulty update: it was caused by a health control that removed healthy servers from service and spread their load across the rest. The most fragile part of a platform is often the one deciding who counts as available. If you like this kind of failure analysis, I keep publishing each week's incidents on the blog with what they teach for your own stack.
