Microsoft 365 Outage: Why “Wait for Microsoft” Fails

Maurice Manning, Principal Cloud Architect, Wursta. 13 November 2026.

Written on Friday 13 November and last checked at 09:45 GMT. At that point Microsoft had not declared the incident resolved or published a root cause, so some of what follows may move.

TLDR

On 12 November, Microsoft 365 went down worldwide. It began with Exchange Online and spread to Teams calendars, SharePoint, Copilot and more. More than fifteen hours later it still wasn’t fixed. Microsoft says it wasn’t an attack, and its own repaired servers kept falling over again once traffic returned. If your continuity plan is to wait for Microsoft, your recovery time is whatever Microsoft’s turns out to be. A rehearsed standby on a separate platform, such as Google Workspace, gives you a say in it. Agents and automations need to be in that plan too.

At 16:17 GMT on Thursday, Microsoft opened incident EX1550543: users in the Americas couldn’t get into their Exchange Online mailboxes. By early evening it had confirmed the problem “may affect Microsoft 365 service connectivity for users in any region”. By the time most of Europe sat down this morning, it was more than fifteen hours old, and Microsoft’s 07:25 GMT update still listed Exchange Online and the wider Microsoft 365 incident (MO1550821) as degraded.

This is the second major Microsoft outage I’ve written about in just over a year. Last time it was an Azure Front Door configuration error that took identity down with it. This one is different in its mechanics and identical in its lesson.

Outlook made the headlines. Downdetector reports for it peaked at nearly 140,000 around 18:00 GMT, according to the BBC as cited by CX Today. But the list of affected services kept growing through the night: Teams calendars and scheduling, SharePoint Online, Microsoft 365 Copilot, Defender XDR, Power Platform flows that depend on Microsoft Graph, and Dynamics 365 Contact Center. New York City’s Emergency Management department warned of delays to email for city agencies and told residents to call 311 or 911 where needed (ABC News). In Australia, Service NSW lost some service-centre and call-centre transactions.

What went wrong, so far

Reading Microsoft’s updates in order is instructive (Tom’s Guide live blog, SecurityWeek, CX Today):

• First, “a portion of infrastructure is experiencing elevated load across multiple regions”.
• Then a correction: the load “isn’t driven by an increase in traffic, but by a number of servers being unexpectedly unavailable”.
• Then servers failing automated health checks, with elevated processor use, possibly originating from “a specific component”.
• At 20:23 GMT: “We’ve not identified any recent change correlated with the start of impact.”
• Overnight: a process “responsible for establishing secure connections becomes overwhelmed”, and Microsoft began reverting “a recent network configuration change that correlates with the start of impact.”

At 07:25 GMT Microsoft said it is “not aware of any malicious activity that is causing this incident.” So this was not an attack.

I’m not criticising the engineers. Anyone who has run a major incident knows the first hypothesis is usually wrong, and the story changes as the data comes in. My point is a different one. For more than fifteen hours, every organisation whose continuity plan was “wait for Microsoft” had its recovery time set by Microsoft’s diagnosis. Their RTO was whatever Microsoft’s turned out to be.

The fix that kept failing

The line that stayed with me was this one: restored servers “can become unresponsive again once they receive traffic”. Microsoft paused deployments, moved traffic off the affected infrastructure and restarted servers, then said those steps had not provided “the anticipated relief”. Patching and rebooting gave only “marginal success” by 06:56 GMT (CX Today).

That is how large outages tend to behave. Recovery isn’t a switch that flips back. If your planning assumes a couple of hours of disruption followed by a clean restore, last night is the counter-example. A recovery time objective you have no way to influence isn’t an objective. It’s a hope.

Three things this outage tells us

Partial failures are harder to manage than total ones. Microsoft said Teams calls, chats and meetings mostly kept working while calendar and scheduling didn’t. People could join a meeting they couldn’t find. Users don’t know which tools to trust, and the helpdesk fills up with “is it just me?”. The decision that matters most is the one most plans leave vague: at what point do we stop waiting and switch, and who makes that call?

Your fallback can’t share the failure. SecurityWeek reported that some Google Workspace users had trouble reaching their mail through Outlook desktop and mobile clients during the incident. I’d want to know why before drawing firm conclusions, but the principle holds either way. If your standby is reached through the same client, the same identity provider or the same network path as your primary, it isn’t independent. It’s a second door into the same room.

Agents fail with the platform they read from. Copilot couldn’t load mail, calendar or files. Power Platform flows failed because Microsoft Graph upstream was failing. OpenAI and Anthropic both reported problems with their Microsoft 365 connectors, with Anthropic attributing it to “a Microsoft 365 service incident” (CX Today). As more work runs through agents and automations, they inherit every dependency of the systems they touch. If an agent drafts customer replies from a shared mailbox, it stops when the mailbox stops. Continuity plans now need to cover automations as well as people.

What “ready” looks like

To be clear, Microsoft 365 is a good platform, and most organisations will and should keep it as their primary. The question isn’t whether to leave. It’s what you do in hour three of an outage.

At Wursta we answer that with a standby Google Workspace environment that runs alongside Microsoft 365, which we call Always-Ready Resilience. Google turned this into a licensed product in October 2025 with two Business Continuity editions: a cold standby with directory sync, usable for up to 21 days a year, and Business Continuity Plus, a hot standby that syncs mail, calendar, Drive, chat and more, usable for up to 60 days a year. Cold suits “people need to email and meet”. Hot suits “they need yesterday’s mail and today’s diary”.

The licences are the easy part. What makes a standby usable at five o’clock on a Thursday is everything around them:

• An agreed declaration process: who can call a disaster, on what trigger, and how quickly support responds once they do.
• Mail flow and DNS decisions made in advance, not improvised during the incident.
• Users who have already signed in, set up MFA and know where to go.
• A switch that has been rehearsed, and is tested again at least once a year.

An unrehearsed continuity plan is a guess. Our approach starts with a short discovery to set RTO and RPO targets in writing, then a four to six week implementation, then managed testing and maintenance.

Before the post-incident review lands

When Microsoft publishes its review, read it. But don’t wait for it before acting. These are the questions I’d put to my own team today:

1. How long were we actually down, service by service, and what did it cost us?
2. Who decided what, and when? Was there a point where someone could have said “switch”?
3. What did people do instead? Whatever they reached for is your current continuity plan, whether you approved it or not.
4. Which automations and agents stopped, and did anyone notice?
5. If this had run for three days rather than one, what would have broken first?

If the honest answer to the second question is “we waited for Microsoft”, that’s the gap worth closing before the next one.

Sources

• ABC News: Microsoft Outlook outage stretches on for hours
• SecurityWeek: Microsoft 365 outage disrupts Outlook, Exchange Online and Teams
• Tom’s Guide: live updates on the Microsoft 365 outage
• CX Today: Microsoft outage cut agents off from the contact center
• Cyber Security News: fixes fail as restored servers keep going unresponsive
• Google Workspace Updates: Introducing Business Continuity editions
• Wursta: Always-Ready Resilience