Microsoft Outage Disrupts Services Worldwide

Microsoft’s cloud services, led by Outlook and Exchange Online, went down for tens of thousands of users from about 18:00 UTC (9pm East African Time) on Thursday 12 November, and the company was still working to restore them on Friday. Microsoft said servers failed automated health checks and became unavailable, which put pressure on the servers still operating. Microsoft had not named a root cause or given a time for full recovery.

Email stopped first. Then Teams. By the time most people had worked out that the problem was not their laptop, Microsoft’s own status page was carrying a list of degraded services that ran well past the inbox. Microsoft logged the incident as EX1550543 for Exchange Online and MO1550821 for the wider disruption. Outlook reports on Downdetector climbed to about 130,000 shortly after 1pm Eastern (18:00 GMT), with some users saying emails weren’t being sent or received and others unable to open their inboxes. Canadian and US reports combined reached nearly 150,000 by 1:30pm ET, and were still above 35,000 at 9:30pm. The counts differ because they come from different views of the tracker at different moments, so “well over 100,000 at the peak” is the fairest description.

Microsoft’s first public statement came from its 365 Status account on X, which said it was investigating problems reaching Exchange Online mailboxes through “multiple connection methods” in the Americas. A spokesperson then told CNBC the problems were “primarily issues with Exchange Online”. The company also said users in any region could be affected.

We’re investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas. More details can be found in the Microsoft 365 admin center under EX1550543.

— Microsoft 365 Status (@MSFT365Status) November 12, 2026

Alongside Exchange Online, Teams, SharePoint Online and Copilot, Microsoft’s impacted-services list included Microsoft Intune, Defender XDR, Defender for Office 365, several Microsoft Purview services covering data loss prevention, auto-labelling, communication compliance and data classification, and parts of the Microsoft 365 Apps admin center including Cloud Update, Cloud Policy and Inventory. Universal Print was affected, as were Power BI exports carrying sensitivity labels, and some Windows 365 Cloud PCs using Purview Customer Key.

Intune is how many organisations manage and push policy to devices. The Apps admin center is where configuration and inventory live. Defender XDR is the security console. Purview is where data loss prevention rules are enforced and sensitive content is labelled. For a period on Thursday, an administrator trying to diagnose a problem affecting their entire workforce could not reliably reach the tools they would normally use to do it, and the security telemetry they would normally watch was itself listed as potentially degraded.

This is the uncomfortable part. The outage did not just take down the things people use. It reached into the things that watch over them. Not everything failed, though. Microsoft said features that did not depend on Exchange Online remained functional.

An explanation that kept changing

Microsoft’s public account moved several times over the first hours. The early read was elevated load. That was then withdrawn. “We determined the elevated load isn’t driven by an increase in traffic,” the company said at 19:30 UTC. The load was a symptom: servers were dropping out, and the ones left standing were absorbing the work.

Why they were dropping out became the next question. By 20:32 UTC, Microsoft’s investigation pointed at automated health checks, and specifically at the component responsible for processing server health. Servers were failing those checks and being pulled from service. A bypass was drafted and began rolling out. At 20:44 UTC, validation stalled because many of the test servers were themselves unresponsive.

“We’ve not identified any recent change correlated with the start of impact,” Microsoft said, while also saying it was assessing whether reverting a small number of recent configuration updates might help. Both statements were accurate descriptions of an investigation in progress. Together they told customers very little.

Partial recovery followed. At 4pm ET, Microsoft said it had validated an alternative health check method that brought some affected servers back online. Teams came back first, with Microsoft saying mitigation had restored its health, and the company said it was “aggressively pursuing all pathways to reduce impact.” That left Exchange Online as the stubborn part.

By 22:11 UTC the company acknowledged that its actions “have not provided the anticipated relief,” and set out a new plan: isolate parts of the infrastructure, restart components, and reintroduce traffic gradually to test stability. Some servers came back. Then, as Microsoft put it, restored servers “can become unresponsive again once they receive traffic.” At 00:35 UTC on Friday, Microsoft said some servers had returned and stayed healthy at first, then stopped responding once traffic reached them. Bringing servers back was not the same as keeping them up.

We’re investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas. More details can be found in the Microsoft 365 admin center under EX1550543.

— Microsoft 365 Status (@MSFT365Status) November 12, 2026

Microsoft said it had seen no indication of a cyberattack. No root cause has been published, and the post-incident review has not yet appeared.

Where it landed

The effects showed up in public services. Hospitals across Canada said their services were affected, and the CHUM network in Montreal said appointment requests and certain international operations were hit. Via Rail said passengers might not receive email about their trips. That is the practical meaning of a productivity platform outage. A hospital system and a rail operator had a worse day than planned.

Some outage-tracker reports also showed problems at other providers, which caused early confusion. Amazon said its services were operating normally and that an unrelated disruption elsewhere was prompting inaccurate news reports. Nothing I found ties this outage to AWS or Google.

The shape of the risk

Microsoft has said what failed. It has not said why, and that second question is where the more useful conversation sits.

Two months ago, a separate Microsoft 365 incident was attributed to a core authentication configuration problem. This one appears to trace to a health-check component. Different parts, same structural consequence.

When mail, chat, files, device management, security detection and data governance all sit on one platform, a fault in a shared internal component does not stay in its lane. It surfaces in every service that depends on it, simultaneously, and the blast radius is defined by the architecture rather than by the severity of the original fault. That reading is ours, not Microsoft’s, but what the company has said is consistent with it.

The World Economic Forum made a version of this point in its Global Cybersecurity Outlook 2026, published in January, when it cited last year’s disruptions at Amazon Web Services, Azure and Cloudflare. None of those were security incidents either. All of them demonstrated how provider-level events cascade through everything built on top of them.

What this costs on the ground

For organisations running on Microsoft 365, the practical damage is measured in things that could not happen. Invoices not sent. Approvals not given. Customer queries unanswered. Meetings that collapsed because the platform they lived on was unavailable.

The advice circulating among administrators during the incident was consistent and worth repeating, because the instinct it warns against is a costly one. A server-side failure is not fixed by rebuilding Outlook profiles, clearing Teams caches or reimaging machines. Doing so burns hours and can leave users worse off once the service recovers.

More useful is the dull discipline of record-keeping. Organisations should log when users lost access, which services were affected and what work was disrupted, both for internal reporting and because service credits under enterprise agreements depend on being able to evidence impact.

And when the service does come back, the catch-up matters. Intune device check-ins, Defender alerting and Purview labelling and data loss prevention policies will all have a gap in them covering the outage window. Queued mail will arrive late. Those gaps need reviewing rather than assuming they closed themselves.

The question worth putting to any technology team this week is narrow. If Microsoft 365 is degraded for twelve hours, what is the agreed channel for telling staff, and does it depend on Microsoft? If the answer is a Teams message or an email, it is not an answer.

Most organisations will stay on Microsoft 365, and for good reasons. The useful step is to work out what the business would lose if it went down, and to agree on a way of reaching staff that doesn’t depend on it. Microsoft has not yet said what set the failure off or when full recovery will come. Its post-incident review should show whether this was a one-off or something customers should plan for again.