On Thursday 12 November 2026, Outlook and the Microsoft 365 services that depend on Exchange Online went down in more than 70 countries, and full service…
// the short version
On Thursday 12 November 2026, Outlook and the Microsoft 365 services that depend on Exchange Online went down in more than 70 countries, and full service only came back on Saturday. Microsoft's updates say servers were failing automated health checks and becoming unavailable, with "a number of servers being unexpectedly unavailable; straining the remaining infrastructure."
// what to take away
- From 12 to 14 November 2026, Exchange Online servers failed their automated health checks and became unavailable, taking down Outlook and the Microsoft 365 services that depend on it, including Teams calendars, Copilot, Safe Links and the admin tools, for users in more than 70 countries.
- Microsoft's updates describe servers unexpectedly unavailable, the remaining infrastructure strained, and a core process on the affected servers overwhelmed. That is the shape of a cascading failure: each server that drops out moves its load onto the rest. Servers restored with an alternative health check stayed healthy only until traffic reached them.
- Recovery was deliberately gradual: isolate part of the infrastructure, restart it, reintroduce traffic slowly, then widen. Microsoft told CNBC the issue began during an earlier network capacity upgrade and has promised a full post-incident review with the root cause.
What broke, and for how long
Users in the Americas started losing access to Exchange Online mailboxes on Thursday 12 November 2026; Microsoft first acknowledged it at 17:54 UTC and the main incident, MO1550821, is logged from 18:26 UTC. It spread to users in more than 70 countries. Broad recovery came through Friday 13 November, region by region (Microsoft described Japan as comparatively stable and reported progress in Europe and then North America), and Microsoft said on Saturday 14 November that service was restored for the remaining customers.
The core was Exchange Online, Microsoft's hosted email. The damage followed everything that talks to it. Microsoft's own impact list on 13 November included:
- Outlook on the web, desktop and mobile: mailboxes unavailable, mail delayed.
- Teams: calendar, meeting scheduling and some chat creation, which depend on Exchange. Core messaging and online meetings stayed largely up.
- Microsoft 365 Copilot: chat failing to load or answer, and no access to mail, calendar or files.
- Defender for Office 365: Safe Links unable to verify URLs, which affects every link clicked in Outlook and Teams.
- Admin tools: Microsoft 365 admin center pages, the Apps Admin Center and Intune, which meant admins had trouble seeing what was wrong.
- Also listed: Graph API calls touching mail and calendars, Planner, To Do, Purview, Power BI and Fabric exports with sensitivity labels, Universal Print and some Windows 365 Cloud PCs.
What Microsoft says happened
In order, from Microsoft's updates:
1. Servers failed their health checks. "A problem that's causing servers to fail automated health checks and become unavailable." Early on, Microsoft said the failures "may originate from a specific component that's responsible for processing server health." 2. Capacity left, and the rest was strained. Microsoft's Thursday updates described "a number of servers being unexpectedly unavailable; straining the remaining infrastructure." Later updates also mention "traffic management imbalances" and "the underlying cause of the traffic influx"; whether load or lost capacity came first is for the post-incident review to say. 3. A core process was overwhelmed. "A core process on the affected servers is becoming overwhelmed, which causes the servers to stop responding and contributes to the capacity loss." 4. Fixes didn't hold. "Actions taken thus far have not provided the anticipated relief." Microsoft validated an alternative health check method that let some servers return, but they "initially remain healthy" and "can become unresponsive again once they begin receiving traffic." Scaling up virtual machines ran into "machines being stuck in a bad state, preventing our changes from syncing as expected." 5. The recovery that worked was gradual. "Fully isolating a portion of our service infrastructure, restarting the affected components, and gradually reintroducing traffic to confirm our services remain stable before applying this approach more broadly," along with traffic management and moving connections to alternative paths. 6. Mail was protected. The email timeout window was extended to 48 hours so delayed messages kept retrying instead of bouncing. 7. The cause, so far. Microsoft told CNBC the disruption stemmed from "an issue during an earlier network capacity upgrade," and told the BBC it was not a cyber-attack or an AI agent. A full post-incident report "with root cause and defense-in-depth actions" is promised.
Why failing health checks can take down healthy servers
A load balancer spreads users across a fleet of servers and asks each one, every few seconds, whether it's OK. A server that answers wrong, or doesn't answer in time, is taken out of rotation so nobody is sent to it. With one broken server that's exactly right: its share of users moves to the rest, and each of them takes a little more.
The trouble starts when a lot of servers fail at once. Their users don't disappear; they reconnect, and all of that load lands on the servers still in rotation. If those were already near their limit, the extra load pushes them over: they slow down, miss their own health checks or stop responding, and they are pulled out too. Each server that leaves makes the next one more likely to follow. That's a cascading failure. Microsoft's updates fit the shape (servers unavailable, the rest strained, a core process overwhelmed, capacity lost), though its full review will say exactly how the steps connected.
It also explains the relapse. A server that has just restarted has no users, so it passes a health check easily. The moment the load balancer trusts it, it receives a full share of a backlog that has been building for hours, and if that's more than it can take, it fails again. Bringing servers back one at a time can never catch up; the fix is to bring back enough capacity together, and to let traffic in slowly enough that each step holds. That's what "isolate, restart, reintroduce traffic gradually, then widen" does.
The general guards against this
These are common practice in large services. They are not claims about what Microsoft does or doesn't do internally, which isn't public.
| Guard | What it prevents | | --- | --- | | Headroom in every slice of the fleet | The remaining servers can absorb the load of the ones that drop out | | Health checks that tell busy from broken | An overloaded but working server keeps its traffic instead of handing it on | | A cap on how much a health check may remove at once | A fault in the health-check path itself can't drain the whole fleet | | Load shedding and admission control | Servers reject excess work early and stay up | | Cells with independent capacity | A failure stays inside one cell | | Staged rollouts with an automatic pause | A bad change reaches a small slice before it reaches everyone |
Terms
- Health check
- a periodic request a load balancer sends to each server to decide whether to keep sending it users.
- Out of rotation
- removed from the set of servers a load balancer sends traffic to.
- Cascading failure
- a failure that spreads because each component that fails pushes more load onto the ones left.
- Post-incident review (PIR)
- the provider's written account of root cause and fixes, published after an incident.
Questions
Was it a cyber-attack?
Microsoft says no: it reported "no evidence of malicious activity" during the incident and later told the BBC it was not a cyber-attack.
Was Azure down?
The impact Microsoft listed is Microsoft 365 services that depend on Exchange Online; it did not describe an Azure incident in these updates.
Will Microsoft publish the root cause?
It has said it will publish a full post-incident report with root cause and defense-in-depth actions. This page will be updated when it does.
// further reading
- Microsoft 365 service health status ↗: Microsoft's status page, where the post-incident review for MO1550821 is due.
- Microsoft struggling to fix massive cloud outage that's taken down email and Intune ↗: The Register, 12 November 2026, quoting @MSFT365Status as it happened.
- Microsoft's massive M365 outage stretches past 27 hours as its fixes keep failing ↗: The Register, 13 November 2026, on the health check workaround and the relapses.
- Microsoft says services fully restored after day-long global outage ↗: BBC News, 14 November 2026, with Microsoft's statement on the network capacity upgrade.
// transcript
Outlook went down in seventy countries for nearly a day, and Microsoft says its servers just kept failing their own health checks. A health check is a tiny question a load balancer keeps asking every server: are you OK? Answer wrong and you're pulled out of rotation, so nobody lands on a broken machine, which is exactly what you want when one server breaks. On Thursday, the servers behind Exchange Online, Microsoft's email service, started failing those checks at once. Their users didn't leave, they reconnected to the servers that were left, and in Microsoft's words, servers being unexpectedly unavailable were straining the remaining infrastructure. On the affected servers, a core process was getting overwhelmed, so they stopped responding, and even more capacity was lost. That's the shape engineers call a cascading failure, where every server that drops out puts more load on the ones still standing. So engineers switched to a different way of checking health, and a batch of servers came back green, but a server can look healthy while nobody's using it, and once traffic reached them, some stopped answering again. Adding capacity didn't save it either, because machines got stuck in a bad state. And since so much of Microsoft 365 leans on Exchange, the damage spread, to calendars in Teams, Copilot, Defender's link checks, and even the admin tools people needed to see what was wrong. The way back was slow on purpose: isolate a slice of the service, restart it, let traffic back in gradually, and only then widen it, while email could wait in queues for up to forty-eight hours instead of bouncing. By Saturday, Microsoft said everything was back, and pointed to an issue during an earlier network capacity upgrade, with a full review still to come. The usual guards are spare capacity, checks that can tell busy from broken, a limit on how much of a fleet they can pull at once, and rolling any change out to a small slice before it reaches everyone. A health check protects you from one broken server, but it can't help much when every server looks broken at once.
// source
This explainer is based on Microsoft 365 service health: incident MO1550821 by Microsoft ↗. The original reporting and technical work belong to its publisher.