What Microsoft is going through tonight is historic, and I do not use the word for effect. Exchange Online began turning people away at 11:17 this morning, Eastern time, and it is still doing so as I write, close to eleven hours later. Downdetector counted about 130,000 Outlook reports at the peak. January's outage, the one The Register clocked at nearly ten hours, peaked at 15,000.
It did not stay inside email. The Microsoft 365 admin center stopped loading. Teams, SharePoint, Copilot, Defender XDR, Purview and Intune joined the affected list one after another. The fault reached every region. It landed in Australia on Friday morning, where Service NSW, Queensland Health and the NSW Parliament were among those hit and the National Cyber Security Coordinator is now looking into it. In New Zealand it held up house settlements.
Microsoft has published no root cause and no restoration time. So part of what follows is my own reading of the status notices, and I say so wherever that is the case.
Where things stand tonight
| Status Open, service degradation |
Root cause Not published |
| Started 11:17 am ET (16:17 UTC) |
Incident IDs EX1550543 (Exchange Online), MO1550821 (Microsoft 365 suite) |
| Restoration ETA None given |
Latest Staged restarts are holding in isolated parts of the infrastructure. A later change is not taking as expected. |
Downdetector reports for Outlook had fallen to about 30,000 by 7:12 pm, so a good share of users are back. That number measures complaints. It does not measure capacity, and CNN still described the outage as widespread at 10 pm.
The chronology
Times are Eastern, with UTC underneath. Unless I name another source, each entry comes from Microsoft's notices for EX1550543 and MO1550821 or from the Microsoft 365 Status account.
| Prelude | |
| 9:45 am 14:45 UTC |
Teams messaging degrades for users in the Americas (TM1550488). Microsoft's preliminary cause is resource contention in the underlying infrastructure. It is closed at 10:53 am. Microsoft has not connected it to what came next. |
| Detection | |
| 11:17 am 16:17 UTC |
Official start of EX1550543. Three minutes later Microsoft says it is investigating mailbox access problems. |
| 11:55 am 16:55 UTC |
Telemetry review. The notice names the affected connection methods: Outlook on the web, MAPI, Exchange ActiveSync and the REST API. That is every door into a mailbox. |
| 12:45 pm 17:45 UTC |
Connectivity errors are located on the part of the infrastructure that receives and processes access requests. Networking logs are collected. |
| 12:54 pm 17:54 UTC |
First public post from Microsoft 365 Status, scoped to the Americas. Thirteen minutes later the scope becomes users in any region. |
| Escalation | |
| ~1:15 pm ~18:15 UTC |
Downdetector's Outlook count nears its peak of roughly 130,000. UK Teams reports jump. Users find the status page itself will not load. |
| 1:19 pm 18:19 UTC |
First explanation: elevated load across multiple regions. Microsoft starts restarting and repairing infrastructure. |
| 1:26 pm 18:26 UTC |
MO1550821 opens for the wider suite: Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR. Microsoft is reviewing an unexpected rise in one type of service traffic. |
| 1:43 pm 18:43 UTC |
Servers are intermittently unavailable. Outlook connection traffic is redistributed across the worldwide infrastructure, a step completed by 1:57 pm. |
| 2:06 pm 19:06 UTC |
Every deployment and configuration change is paused while recent changes are reviewed. |
| Diagnosis | |
| 2:18 pm 19:18 UTC |
The correction. Traffic had not grown. A large number of servers had dropped out, and the survivors were carrying their share. |
| 2:43 pm 19:43 UTC |
The servers are failing automated health checks, possibly because of a recent change to the component that processes those checks. A configuration change is tested on a subset. |
| 2:57 pm 19:57 UTC |
No recent change lines up with the start of impact. The failed checks may come from one specific component, so Microsoft deploys a targeted bypass, blocks further server removals and starts looking at high processor usage. Planner and To Do join the affected list. |
| 3:38 pm 20:38 UTC |
Many servers go unresponsive while the bypass is being validated. They are restarted with the change in place. |
| 3:56 pm 20:56 UTC |
An alternative health check method works on a subset, and those servers return to service. Microsoft prepares automation to detect and restart unresponsive servers and begins examining a small number of recent configuration updates. Several Purview services are added to the list. |
| Recovery stalls | |
| 4:31 pm 21:31 UTC |
Restart and validate, server by server. Reverting the recent configuration updates is under assessment. |
| 5:00 pm 22:00 UTC |
Microsoft concedes its actions so far "have not provided the anticipated relief." A core process on the affected servers is being overwhelmed until they stop responding. The status page, as Gizmodo quoted it, identifies that process as the one "responsible for establishing secure connections." New plan: isolate part of the infrastructure, restart it, feed traffic back gradually, and consider isolating whole regions. Intune, Defender for Office 365, Purview DLP and auto-labelling are now on the list. |
| 5:57 pm 22:57 UTC |
A portion of the servers is back and stable. Traffic moves to alternative pathways, some regions see limited recovery, and protective traffic measures go in at one location. |
| 6:59 pm 23:59 UTC |
The relapse. Restored servers look healthy, then fail once they take traffic. Networking and platform specialists are on the diagnostics. Certain traffic types are limited in specific locations, and a subset of servers is being rebuilt on a previous software configuration to see whether that stops the failure. |
| Staged recovery | |
| 8:59 pm 01:59 UTC |
The first good news in hours. Restarting infrastructure in isolation and recovering server availability piece by piece is producing positive results. Microsoft is watching those pieces for stability before expanding the approach. |
| 9:29 pm 02:29 UTC |
Capacity is added where possible to support the regions coming back online (CNN). |
| after 9:30 pm after 02:30 UTC |
A setback. Microsoft 365 Status reports that changes applied to improve serviceability are not taking as expected. The incident stays open. |
Reuters also reported trouble with the Microsoft connectors used by OpenAI's and Anthropic's assistants during the afternoon. Azure's own status page listed no active events.
Five explanations in six hours
Read the notices in order and the story changes five times. Elevated load. Then servers dropping out, with no extra traffic behind it. Then failed health checks, traced to a component that processes them. Then a core process overwhelmed on the servers themselves. And at 6:59 pm, servers that pass every check and still fall over under traffic.
I do not hold that against the engineers. Each statement was the best reading of the telemetry at that minute, and Microsoft published them quickly, including the one admitting the fixes had not worked. But the sequence matters for anyone guessing at the cause. The health check theory was the favourite at 3 pm. By 7 pm it could not explain what the servers were doing.
What I think happened
Everything in this section is assumption. Microsoft has confirmed pieces of it and none of the whole.
The failing tier is the one that accepts client connections and routes them to mailboxes. Microsoft described it at 12:45 pm as the infrastructure that receives and processes access requests, and the list of broken protocols fits: when OWA, MAPI, ActiveSync and REST all fail together, the mailbox databases are usually fine and the front door is not.
The detail that narrows it down is the overwhelmed process. A process that establishes secure connections is, in my reading, the TLS termination layer. A full TLS handshake is the most processor-hungry thing a front-end server does for a client. Resumed sessions are cheap. New ones are not.
My reading of the chain, step by step. Blue steps are confirmed by Microsoft. Grey steps are mine.
| 1 | Something makes new secure connections more expensive or more frequent on the access servers. A change, a defect, expired session state. The trigger is unknown. My assumption |
| 2 | The process that establishes secure connections saturates the processors, and the server stops handling requests. Microsoft, 2:57 pm and 5:00 pm |
| 3 | A starved server answers its health probes late or never. It fails the automated checks. Microsoft, 2:43 pm |
| 4 | Automation pulls it out of rotation. The remaining servers inherit its clients and tip over the same threshold. Microsoft, 2:18 pm |
| 5 | Millions of disconnected Outlook, mobile and API clients retry. Every retry needs a new secure connection, which is the one operation already saturated. My assumption |
| 6 | A restarted server is healthy until traffic arrives. Then it goes back to step 2. Microsoft, 6:59 pm |
Under this reading the health check component was an amplifier. It did what it was built to do, on servers that were sick, with no brake on how many it could remove at once. Microsoft's 2:57 pm step of blocking further server removals points the same way.
There are competing readings, and I have ranked them by how well they fit the evidence so far.
| Hypothesis | What supports it | What does not fit |
| A defect or change on the access servers that surfaces under peak load Most likely |
High processor usage, an overwhelmed secure-connection process, relapse under traffic, and the decision to rebuild servers on a previous software configuration. | Microsoft found no change that correlates with the start. A change that only bites above a load threshold would not correlate, though. |
| Faulty health check component ejected healthy servers Contributing |
Microsoft's own 2:43 pm and 2:57 pm notices. The alternative check method did return a subset of servers. | Servers with the check bypassed still went unresponsive. A false alarm does not do that. |
| Reconnect storm keeps the system down Sustaining |
Limits on traffic types, gradual reintroduction, protective measures at one location, and the fact that isolated restarts are what finally worked. | It explains why recovery is slow. It cannot explain what started the outage. |
| Attack or hostile traffic Unlikely |
The 1:26 pm note about an unexpected rise in one traffic type. | Microsoft withdrew the traffic explanation at 2:18 pm and told Forbes Australia there is no indication of a cyber attack. Nobody has claimed one. |
One loose thread. Teams messaging in the Americas degraded at 9:45 am with a preliminary cause of resource contention, ninety minutes before Exchange. Microsoft treats it as a separate, closed incident. Same morning, same geography, same family of symptom. I would not be surprised to see the two share a paragraph in the final report, and I have no evidence that they will.
Restarting is not recovering
The 6:59 pm notice is the most informative thing Microsoft published all day. Servers that return to rotation stay healthy until they start receiving traffic, and then stop responding.
Distributed systems people call this a metastable failure. The original trigger can be long gone, and the system stays down anyway, because the recovery load is heavier than the normal load. A mailbox client that has been disconnected for six hours does not come back politely. Its cached session is stale, so it negotiates a new secure connection from scratch, authenticates again and resynchronizes. So do the other clients queued behind it. A freshly restarted server takes that wave in its first minute, on the exact code path that was already struggling.
Which explains the shape of the evening's work. Microsoft stopped trying to bring everything back at once and began rationing: isolate a slice of infrastructure, restart it, admit a little traffic, watch, admit more. Slow, and correct. It is also the first approach that produced good news, at 8:59 pm. And it explains why some people had Outlook back at 6 pm while a colleague two desks over did not.
The rebuild on a previous software configuration is the other tell. You do not reimage servers to an older build if you believe the software on them is sound.
The status page was inside the blast radius
The admin center, where tenant administrators are told to read incident notices, was unreachable for much of the afternoon. Microsoft redirected people to status.cloud.microsoft and to its account on X. Defender XDR, Purview and Intune portals were on the affected list too, so for several hours a security team could neither read its alerts nor read about why.
Every large provider relearns this one. The channel that reports an outage has to survive the outage, which means it cannot share an identity path or a front door with the thing it reports on.
If you run a tenant
Leave it alone. That is most of the advice. Do not repoint MX records, rebuild Outlook profiles, delete OST files or reconfigure connectors while EX1550543 is open, because none of those touch the fault and each one adds a second problem to untangle on Friday.
Nothing in Microsoft's notices describes lost mail. The fault is in reaching mailboxes. External senders' servers queue and retry by design, so expect a late burst of delivery as capacity returns.
Once the incident closes, look at the hours when Defender, Purview DLP and Intune were degraded. Alerts may have arrived late and policy evaluations may have been skipped. Microsoft has not said so, but I would check before assuming the afternoon was quiet.
What I will look for in the post-incident report
Microsoft normally publishes a preliminary report within two business days of closing an incident like this and a final one within five. Four questions I want answered:
- What changed on the access servers, and when, relative to 11:17 am?
- How many servers could the health system remove at once, and was there a floor?
- Why did Teams, SharePoint and Defender follow Exchange down, and through which shared dependency?
- Was the 9:45 am Teams incident an early warning?
I will update this post when the report lands. If my chain above turns out wrong, I will leave it up and mark where.
Sources
Microsoft incident notices EX1550543 and MO1550821, as mirrored by Cloud Admin Hub: cloudadminhub.com
Microsoft 365 Status on X, posts of November 12 and 13, 2026: x.com/MSFT365Status
StatusStack, Microsoft 365 and Exchange Online connectivity issues, November 12, 2026: statusstack.com
Gizmodo, Microsoft 365 outage stretches late into the evening, November 12, 2026: gizmodo.com
CNN, Microsoft outage strands office workers around the world, November 12, 2026: cnn.com
Forbes Australia, Outlook and Teams still down as fixes stall, November 13, 2026: forbes.com.au
Stuff, Global Microsoft outage hits NZ, November 13, 2026: stuff.co.nz
TechCrunch, Microsoft's Outlook email hit by new outage, November 12, 2026: techcrunch.com
Tom's Guide live coverage, November 12, 2026: tomsguide.com
WindowsForum, MO1550821 megathread, November 12, 2026: windowsforum.com
The Register, Microsoft 365 outage drags on for nearly 10 hours, January 23, 2026: theregister.com
Comments