Microsoft 365 Outage (Nov 2026): What We Know About the Cause

Last updated: 13 November 2026, ~06:30 UTC. The incident is still open, and Microsoft has not published a root cause. We'll update this post when Microsoft releases its post-incident review.

On Thursday, 12 November 2026, a large Microsoft 365 outage stopped businesses around the world from opening their mailboxes. It started in Exchange Online and then spread to Outlook, Teams calendars, SharePoint, Copilot, Defender and every other part of Microsoft 365 that depends on email. Microsoft is tracking it under two incident IDs in the Microsoft 365 admin center:

• EX1550543: the Exchange Online incident (mailbox access)
• MO1550821: the broader Microsoft 365 incident, with the full list of affected services

This post covers what happened, what Microsoft has actually said about the cause so far, whether it was a cyberattack, and what a small or mid-sized business should do now and before the next outage. Every claim about the cause below is attributed to Microsoft and dated, because the explanation has already changed once during the incident.

Timeline: what happened

All times are UTC, which is the same as UK time in November. US Eastern is UTC−5.

Microsoft also logged a separate, shorter Teams incident that afternoon, TM1550488. It caused delayed chat messages in the Americas from 14:45 to 15:53 UTC and has been resolved. Microsoft's preliminary cause for that one is "resource contention". ¹ It is not the same incident as EX1550543.

Seeing claims that Microsoft's job cuts caused this? We looked into it: Did Microsoft layoffs cause the Outlook outage?

What is affected

According to MO1550821, features that "interact with Exchange Online and email services are impacted". Parts of those services that don't depend on Exchange Online keep working. ^{1 7} In practice, that means:

• Exchange Online / Outlook: no mailbox access through Outlook on the web, desktop Outlook, mobile mail or the REST API, and email delivery may be delayed. Most delayed mail should arrive once service returns, but sending servers only retry for a limited time.
• Teams: calendars and meeting scheduling may fail. Core chat and meetings "remain largely functional".
• SharePoint Online: features that depend on email fail, but files can still be opened.
• Microsoft 365 Copilot: Copilot Chat may not load, or may not be able to reach email, calendars or files.
• Defender for Office 365: Safe Links may be unable to check URLs, so users can see errors on harmless links in Outlook and Teams.
• Defender XDR and Purview: portal pages may not load, and data loss prevention (DLP) and labelling features are affected.
• Microsoft Graph: mail, calendar and contacts calls may time out. Any custom integration, CRM sync or automation that reads mailboxes through Graph will fail too.
• Also listed: Planner, To Do, Intune, Power BI exports, Universal Print, Windows 365 (some tenants) and parts of the admin center itself.

That last point catches many businesses out. If your internal tools sync email into a CRM, create tickets from a shared mailbox or send invoices through Microsoft 365, those workflows stopped too, even though "your" software is fine.

What caused the Microsoft 365 outage?

Short answer: Microsoft has not confirmed a root cause yet. Here is what it has said, in order, and what that suggests.

1. Servers were dropping out, not traffic spiking

Early in the incident, Microsoft ruled out the obvious explanation:

"We determined the elevated load isn't driven by an increase in traffic, but by a number of servers being unexpectedly unavailable; straining the remaining infrastructure." ³

This is a classic cascading failure. When some servers leave the pool, their share of users moves to the remaining servers. Those servers then overload and fail, which pushes even more load onto fewer servers.

2. Health checks were taking servers out of service

Microsoft then said the affected servers were failing automated health checks. That is the system a load balancer uses to decide whether a server should receive traffic. Microsoft's first theory was that the health-check component itself was at fault. ⁴ It tested a different health-check method, and some servers came back. ¹

3. The real bottleneck: a "secure connections" process overwhelmed

Overnight, the explanation changed. Microsoft said:

"A process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests." ^{1 7}

As azureblog.co.uk points out, this means the health checks were probably right to fail those servers, because the servers really had stopped working. ¹ It also explains the worst part of the outage: servers that were restarted came back healthy, received a flood of reconnecting clients, and fell over again. ⁶ Setting up encrypted (TLS) connections is CPU-heavy work. When millions of Outlook clients all reconnect at once, the reconnection traffic alone can knock a server down again. SecurityWeek separately reported that Microsoft was investigating elevated processor usage on the affected servers. ⁷

4. A network configuration change "correlates with the start of impact"

At about 19:57 UTC on 12 November, Microsoft said it had found no recent change linked to the outage. ⁴ A few hours later it said it was "assessing whether reverting a small number of recent configuration updates" could help. ⁹ Overnight it said it had "begun reverting a recent network configuration change that correlates with the start of impact". ^{1 7}

Correlation is not a confirmed cause. Rebuilding servers "using a previous software configuration" ⁶ and reverting a network change strongly suggest that Microsoft suspects a recent change. Wait for the post-incident review before treating that as the answer.

What we can say with confidence today

The outage was not caused by a traffic spike. Servers became unable to handle secure connections, the load cascaded across the remaining infrastructure, and restored servers kept failing again under reconnection load. A recent network configuration change is the leading suspect, but Microsoft has not confirmed it.

Was it a cyberattack?

There's no evidence of one. Microsoft's service advisories have not reported any malicious activity, and its updates describe an infrastructure and configuration problem. ⁷

The outage did come two days after Microsoft's November Patch Tuesday, which included CVE-2026-124194, an Outlook spoofing flaw Microsoft says has been exploited. Microsoft has not linked that vulnerability to this outage. ⁷ Patch it anyway, but don't connect the two without evidence.

The real security risk is what attackers do during an outage. Watch out for:

• Phishing emails telling users to "re-verify your Microsoft 365 account" or "restore your mailbox"
• Fake "Microsoft support" phone calls offering to fix the outage
• Fake status pages

Microsoft's real status sources are the admin center (Health → Service health), status.cloud.microsoft and the @MSFT365Status account on X. Nobody needs a user's password to fix a datacenter problem.

What to do right now if Microsoft 365 is down

You can't fix an outage inside Microsoft's datacenters, so don't spend hours troubleshooting your own tenant. The essentials, briefly:

• Confirm it's Microsoft. Check Health → Service health in the admin center. If the admin center won't load, use status.cloud.microsoft and follow EX1550543 / MO1550821 rather than news headlines.
• Reach staff outside Microsoft 365, for example by SMS or WhatsApp, because Outlook and Teams may not deliver your announcement.
• Pause your own deployments, so any new problem after recovery is clearly upstream, not something you changed.

azureblog.co.uk has a thorough admin checklist, covering alert setup, the Admin mobile app and service-health monitoring through Graph. ¹ We won't repeat it here. The part most coverage skips is what happens to your own software during an outage like this.

The hidden damage: integrations that fail silently

Microsoft listed Microsoft Graph mail, calendar and contacts requests as timing out. ¹ Most SMBs don't think of themselves as Graph users, but many of their tools are:

• A CRM that logs customer emails from Outlook
• A helpdesk that creates tickets from a shared support@ mailbox
• An invoicing or ERP system that sends documents through Exchange
• Booking tools that write appointments into Outlook calendars
• Low-code flows (Power Automate, Zapier, n8n) triggered by "new email arrived"

When Graph times out for 14+ hours, each of these does one of three things. Only the first is acceptable:

1. It retries later and catches up. This is good.
2. It gives up quietly. A support ticket is never created, an invoice is never sent, a lead's email is never logged, and nobody notices until a customer complains.
3. It retries too aggressively and creates duplicates. When the backlog of delayed mail arrives all at once, the same message gets processed twice, producing duplicate tickets, duplicate CRM activities, or a customer who gets the same invoice twice.

What a resilient integration does differently

These are the patterns we build into integrations, and the questions to ask whoever maintains yours:

• Retries with exponential backoff and a cap. It backs off when Microsoft returns errors or throttling responses (HTTP 429/503) and honours the Retry-After header, instead of hammering a struggling service. (Microsoft's own servers were falling over under reconnection load in this incident, so clients that back off are part of the solution.)
• Idempotency. Each email, event or document is processed using a stable ID, such as the message's internetMessageId, so processing it twice has no extra effect. This is what prevents duplicates when the backlog floods in.
• A durable queue and a dead-letter queue. Work that can't be completed is stored rather than dropped. Items that keep failing go to a dead-letter queue that a person reviews.
• Delta sync instead of "since the last run". Graph delta queries let an integration pick up exactly where it left off after a long gap, rather than missing a window of messages.
• An alert when the integration itself is unhealthy. If the CRM sync hasn't succeeded in 30 minutes, someone should be told. Alerts shouldn't depend only on Microsoft's status page.

After service returns: a reconciliation checklist

Once EX1550543 is resolved, spend an hour on this before declaring all clear:

1. Check for gaps. Compare counts for the outage window. Did the helpdesk create tickets for every email that reached the support mailbox?
2. Check for duplicates. Look for repeated CRM activities, tickets or sent documents with the same source message.
3. Re-run anything that failed permanently. Review any dead-letter queue, failed flow run or error log covering 12–13 November.
4. Check for bounces. Sending servers retry for a limited time only. Ask key customers and partners whether anything they sent you bounced, and have them resend it.
5. Save Microsoft's post-incident review when it is published. Service health keeps only 30 days of history, and you'll want it for SLA conversations. ¹

Every major SaaS platform has outages, including Microsoft, Google and AWS. You can't prevent them, but you can decide in advance whether your business loses data and customers' messages when one happens.

How Ibistra Tech helps

We build and run business software for SMBs: custom applications, integrations with platforms like Microsoft 365, and managed services with uptime monitoring and incident response. If this outage showed you that your systems break silently when an upstream provider fails, that's fixable. See our Managed Services or talk to us about your integrations.

This post will be updated when Microsoft publishes its post-incident review for EX1550543 / MO1550821. Until then, treat any single "root cause" you read elsewhere with caution.