The day after the Microsoft 365 outage: what we learned and what you can do now

On Thursday 12 November 2026, Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR failed or ran degraded worldwide. This post sorts it out: what is documented, what is still open, what we learn from it, and what you can do today without rebuilding your whole infrastructure.

The question of how dependent you want to be on a single vendor is covered in Microsoft 365 outage and dependency. This post is about the analysis and the concrete steps afterwards.

State of the information: Microsoft has not published a final post-incident review yet. Everything below rests on Microsoft's status updates as summarised by BleepingComputer and on a technical analysis by Control Plane. The analysis is an interpretation, not a confirmation by Microsoft.

What is confirmed

• Start: the main incident (admin center ID MO1550821) began on 12 November at 18:26 UTC with Exchange Online problems in the Americas and spread to other regions and dependent services. A shorter Teams incident (TM1550488) ran the same day between 14:45 and 15:53 UTC; Microsoft has not said whether the two are related.
• Cause according to Microsoft: first elevated load, then a number of servers becoming unexpectedly unavailable and straining the rest, later a core process on affected servers being overwhelmed. Traffic did not rise. What triggered the first failures has not been published.
• No attack: Microsoft sees no sign of malicious activity.
• Mitigation: deployments paused, traffic redistributed, servers restarted, the health-check method switched, a few recent configuration changes reviewed for rollback, and the mail delivery timeout window extended to 48 hours.
• Recovery: on 13 November Microsoft reported improvement in North America and much of Europe, and significantly shorter mail queues by the afternoon. Reports from 14 November say services are back; an official end and root-cause report are still outstanding.

What the analysis suggests (not confirmed)

The description fits a known pattern, the cascading failure: health checks take sick servers out of rotation, their load lands on the remaining ones, and those fail the checks too. The load per server keeps rising although traffic stays flat. Servers that were returned to service are said to have failed again under load. That explains why recovery took hours and not minutes. It does not explain what caused the first failure; that is the question for the final report.

What we learn from it

1. One vendor, one big blast radius. Mail, chat, files, calendar and Defender XDR ran on one strand. If you detect incidents in Defender and discuss them in Teams, you were blind and mute at the same time during the first hours.
2. Alerts by mail through the same vendor are not alerts. When the vendor fails, the warning does not arrive either.
3. The status messages changed. From “elevated load” to “servers unavailable” to “core process overwhelmed”. That is normal while debugging, but it means: do not pass on first assessments as the final word.
4. Recovery has a long tail. Even after “it works again”, queues drain and mail arrives late.
5. Rumours arrive instantly. “Cyberattack” shows up in every big outage. Wait for the vendor's statement and tell your team only what is documented.

Ten steps for today

1. Find out what was lost. Check the mail queue and the bounce messages of your mail gateway for messages from 12 and 13 November that did not arrive. Ask important senders.
2. Define a communication path outside Microsoft. A phone tree, a messenger or an emergency page on different infrastructure. Write down who triggers it and who announces it.
3. Set up two emergency admin accounts (cloud accounts, separate from the normal ones, strongly protected and monitored). Microsoft describes this as emergency access accounts.
4. Route alerts over a second path. Monitoring that emails you also needs SMS, push or another mail provider.
5. Monitor from outside. A small test that regularly sends a mail to your mailbox and checks that it arrives shows you an outage before your colleagues do. Also subscribe to the service health feed.
6. Know your MX and DNS setup. What are the TTLs, who manages the zone, what happens to inbound mail when your mailbox provider is silent for 48 hours? The mail DNS checker shows MX, SPF, DKIM and DMARC of a domain in one step. Do not change MX records in a panic in the middle of an outage; plan a solution beforehand.
7. Map what depends on mail. Password resets, two-factor codes by mail, invoice sending, ticket system, forms. Write the list down and decide what needs a second path.
8. Rehearse the emergency for 15 minutes. Play it through: mail and Teams are gone, how do you reach customers and the team? Fix gaps immediately.
9. Document the damage and read your contract. Duration, affected processes, costs. Check whether service-level credits in your agreement apply and by when you must claim them.
10. Decide deliberately what should run separately. Not everything has to leave Microsoft. But for a few critical things (emergency communication, alerting, credential recovery) a second provider or a service of your own is worth it, for example a chat room on a self-hosted Nextcloud Talk. That is an addition, not a replacement, and it needs its own care.

What to avoid

• Do not loosen security settings to “get back to work faster”.
• Do not make bulk changes to DNS or accounts in the middle of an outage.
• Do not pass guesses about the cause on to customers.

Once Microsoft publishes its final report I will update this post. Until then: the outage was a test you did not plan. Use the result.