If your phone lit up Thursday afternoon with “is email down for you too?” messages, you weren’t alone. Microsoft 365 had one of its worst days in years, and as I write this on Friday it still isn’t fully back. Outlook mailboxes wouldn’t open, mail queued up for hours, and a long list of services that quietly lean on Exchange Online went sideways with it.
I’ve been watching the service health updates roll in all night, and what stands out isn’t just the length of the outage. It’s how a failure in one core service cascaded through so much of the stack.
What happened (so far)
Microsoft’s Exchange Online incident, EX1550543, started around 16:17 UTC on Thursday, November 12, according to the incident timeline LazyAdmin has been tracking. A broader incident for dependent services, MO1550821, followed about two hours later, which is why some outlets put the start closer to 18:00 UTC. Within roughly an hour, Downdetector was logging Outlook complaints from more than 70 countries, and Forbes reported reports peaking around 130,000 on Thursday afternoon.
The blast radius went well beyond email. Depending on which update you read, the affected list included:
- Core collaboration: Outlook on every platform, Teams calendars and meeting scheduling, SharePoint Online, Planner and To Do.
- Security and compliance: Defender XDR, Safe Links, Purview DLP and labelling, and the related admin portals.
- Management and endpoints: Intune, Universal Print, and some Windows 365 Cloud PCs.
- AI and integrations: Copilot, Graph calls for mail, calendar and contacts, and third-party tools built on top of them.
Al Jazeera noted that government systems in Singapore, Japan, Australia and the Philippines were caught up in it too. Microsoft says there’s no sign of a cyberattack.
Why the fixes kept failing
This is the part I find most interesting as someone who has broken plenty of things in a lab. Microsoft’s explanation shifted overnight, which is normal for a live incident, but the shape of the problem is pretty clear.
Servers started failing automated health checks and dropped out of rotation. Their traffic transferred to the remaining servers, which then got overloaded and failed too. Microsoft later said a process that sets up secure connections was getting overwhelmed. Every time engineers brought a batch of servers back, they got slammed by reconnecting clients and fell over again. That’s a classic thundering-herd problem, and it’s brutal at Microsoft’s scale.
The cause is still officially unconfirmed. Early Thursday evening Microsoft said it hadn’t found a recent change that lined up with the outage. A few hours later it began reverting a network configuration change that, in its words, “correlates with the start of impact,” according to WindowsForum’s rundown of the updates. There’s also some confusion about load: The Register quoted Microsoft talking about a “traffic influx,” while Microsoft later clarified that the extra load came from servers going unavailable, not from more users. By Friday morning, Al Jazeera reported Microsoft claiming only “marginal success,” and Forbes cited a newer update reporting better server stability after a patch, but nobody has given a time for full recovery yet.
Why this matters for IT folks
This is the third big Microsoft 365 disruption this year, after a roughly 10-hour North American outage in January and an Outlook lockout in August. If you run a tenant, a few practical points:
- Tell users not to resend mail. Mail is delayed, not lost. Sending servers will retry, and resending just piles more duplicates into the queue.
- Know your SLA math. Microsoft’s financially backed SLA for Exchange Online is 99.9% monthly uptime. Drop below 99% and the service credit is 50%. Below 95% it’s 100%. Credits aren’t automatic: you file a service request with the incident IDs and impact details, or go through your CSP partner.
- Have an out-of-band channel. When email, Teams and Intune share a dependency, your incident comms can’t live there. A Signal group, an SMS tree or even a status page hosted somewhere else is worth setting up now.
- Map your hidden dependencies. A lot of shops didn’t realize their DLP, phishing protection and device management all hinge on Exchange Online until today.
The homelab angle
Every time something like this happens, the self-hosting crowd (me included) feels vindicated with a sense of “See, I told you so!”. Let’s be real, though: running your own mail server is its own kind of pain, and very few of us beat 99.9% at home. The real lesson isn’t “leave the cloud.” It’s that putting email, chat, security and device management behind one vendor’s single service creates one very large point of failure.
Thinking through that concentration risk is the kind of exercise a homelab is great for. Spin up a backup notification path, test what happens to your setup when your email provider goes dark, and figure out which of your “independent” tools aren’t actually independent.
My take
Outages happen to everyone, and I don’t envy the engineers fighting this one. But three major incidents in one year, plus a dependency chain this deep, should prompt a real conversation in a lot of IT departments. I’ll be watching for Microsoft’s post-incident report, and I hope it’s more candid than usual.
How did your org handle it? Did you have a fallback channel ready, or did you find out the hard way that everything runs through Exchange? Let me know.
Sources
- The Register: Microsoft’s massive M365 outage stretches past 12 hours as its fixes keep failing
- Al Jazeera: Microsoft hit by global outages: What happened and why?
- Forbes: Microsoft 365 Outage Extends Into Friday
- LazyAdmin: Microsoft 365 Outage – Current Status and SLA Credits
- WindowsForum: Microsoft 365 Outage: Server Health Checks, Network Rollback and an Unconfirmed Root Cause
- Microsoft 365 Service Health Status