Microsoft 365 outage degraded Exchange, Teams, Copilot and Defender on 12 November

What happened

On Thursday 12 November 2026, Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR failed or ran degraded for organisations worldwide. The picture so far comes from a post-incident write-up on dev.to, which itself builds on Microsoft's status updates as summarised by BleepingComputer and on a technical analysis by Control Plane. Microsoft has not yet published a final post-incident review, so parts of the account remain interpretation rather than confirmation.

The main incident, tracked in the admin center as MO1550821, began at 18:26 UTC with Exchange Online problems in the Americas and then spread to other regions and to services that depend on it. A shorter Teams incident, TM1550488, ran earlier the same day, between 14:45 and 15:53 UTC; Microsoft has reportedly not said whether the two events were connected.

What Microsoft has said

According to the status updates cited by BleepingComputer, Microsoft's description of the cause evolved in stages: first elevated load, then a set of servers becoming unexpectedly unavailable and placing strain on the remainder, and later a core process on the affected servers being overwhelmed. Notably, overall traffic did not increase, and the company has not said what triggered the first failures. Microsoft has stated it found no sign of malicious activity.

Mitigation involved pausing deployments, redistributing traffic, restarting servers, switching the health-check method, reviewing recent configuration changes as rollback candidates, and extending the mail delivery timeout window to 48 hours. On 13 November Microsoft reported improvement in North America and much of Europe, with significantly shorter mail queues by the afternoon. Reports from 14 November indicated services were back, though an official incident closure and root-cause report were still outstanding.

A cascading failure, probably

The Control Plane analysis, relayed in the dev.to post, suggests the symptoms fit a well-known failure mode: health checks pull struggling servers out of rotation, their load shifts onto the remaining ones, and those then fail their checks in turn. Load per server keeps climbing even though total traffic is flat, and servers put back into service are said to have failed again under load. That would explain why recovery took hours rather than minutes, but it does not explain what set off the first failure, which is the question the final report will have to answer.

Guidance for affected organisations

The write-up lays out ten practical steps, summarised here:

• Reconcile lost mail: inspect the mail queue and your gateway's bounce messages for 12 and 13 November, and check with important senders.
• Establish a communication path that does not rely on Microsoft, such as a phone tree, a separate messenger or an emergency page, and document who triggers it.
• Create two emergency access accounts: cloud accounts, separate from everyday admin credentials, strongly protected and monitored.
• Route alerts over a second channel, since monitoring that only emails through the affected vendor cannot warn you during an outage.
• Monitor from outside, for example with a small synthetic test that emails a mailbox and verifies arrival, and subscribe to the service health feed.
• Know your DNS posture: MX records, TTLs, who manages the zone, and what happens to inbound mail if the provider is silent for 48 hours. Changing MX records mid-outage is discouraged; plan a fallback in advance.
• Map everything that depends on mail, including password resets, two-factor codes, invoicing and ticketing, and decide what needs a second path.
• Rehearse the scenario briefly: if mail and Teams vanish, how do you reach staff and customers?
• Document the damage, covering duration, affected processes and costs, and check whether service-level credits apply and by when claims must be filed.
• Decide deliberately which few critical functions, such as emergency communication, alerting and credential recovery, should run on a second provider or a self-hosted service.

Mistakes to avoid

The write-up also warns against loosening security settings to speed up a return to normal, making bulk changes to DNS or accounts during an outage, and passing unverified guesses about the cause on to customers.

Why it matters

The outage illustrates how wide a single vendor's blast radius can be: mail, chat, files, calendars and security detection all degraded at once, and organisations that detect incidents in Defender and coordinate in Teams lost both capabilities simultaneously. It also shows that alerts delivered through the affected vendor are not alerts, that a vendor's early statements often change as an investigation progresses, and that recovery has a long tail of draining queues and delayed mail. Until Microsoft publishes its root-cause report, the event that started the cascade remains unknown.