20 hours without email: what the Microsoft 365 outage showed

On Thursday 12 November, at 16:17 UTC by Microsoft’s own reckoning, Exchange Online started dropping mailboxes. By Friday afternoon the outage had run for more than 20 hours, had reached 74 countries, and had cut email at Australia’s spy agency, the Philippine Supreme Court and a European stock exchange. It was not an attack. Microsoft’s preliminary story is a routine network change that tipped a fleet of servers into a spiral it could not climb out of for most of a day. The cause is the least interesting part. The interesting part is who discovered, all at once, that they run on one vendor.

Contents · 10 sections

TL;DR #

• Microsoft dates the impact from 16:17 UTC on 12 November. Outage.com marked it resolved at 14:24 UTC on 13 November, about 20 hours 22 minutes later.
• Microsoft’s preliminary cause: an earlier network capacity upgrade, then servers failing health checks, overload on the rest, and a retry storm that knocked restored servers over again.
• The post-incident review is not out yet (as of 13 November). Treat the cause as Microsoft’s account, not a verified root cause.
• It was not a cyberattack, according to Microsoft and the Australian government.
• The lesson is concentration: intelligence agencies, courts, exchanges, GP surgeries and local newspapers all made the same sensible choice, so they all failed together.

The timeline, as far as it is documented #

Microsoft told NBC that impact began at 16:17 UTC on 12 November, under incident EX1550543. That figure comes through secondary sources, not a Microsoft page I could read, so treat it as reported rather than documented. The public signal came later:

• Around 17:45–18:00 UTC, users noticed at scale. Downdetector peaked at roughly 130,000 to 140,000 Outlook reports, according to the BBC and the AP, from 74 countries within about an hour.
• At 18:08, Microsoft posted on X for the first time.
• At 18:26, the umbrella advisory MO1550821 opened. It was first scoped to the Americas, then widened to “any region”.
• On Thursday evening, Microsoft said part of its infrastructure was under “elevated load”, and then, importantly, that the load “wasn’t driven by an increase in traffic” but by “a number of servers being unexpectedly unavailable, straining the remaining infrastructure”. It bypassed a component that processes health checks and started reverting recent configuration updates.
• Overnight (00:17–04:29 UTC), restored servers fell over again. Microsoft said fixes were “not taking as expected”. At 05:04 it described a “surge in outbound call volume from routing services to backend servers”.
• On Friday morning came “early stabilisation”. Microsoft extended the email timeout to 48 hours so queued mail would not bounce.
• At 14:24 UTC Friday, the tracker Outage.com marked the incident resolved.
• Around 17:18 UTC Friday, Microsoft said it was a “technical issue not related to cyber or AI/agents”, started by an earlier network capacity upgrade, and reported “broad recovery and stability”. I had not seen a formal “resolved” notice from Microsoft when I wrote this.

One correction, because I saw it repeated: “unusually high demand” did not cause this. A handful of explainers said so, but Microsoft’s own posts say the opposite. The servers were overloaded because their neighbours had dropped out, not because more people were sending email.

Microsoft’s preliminary cause chain #

Put together from the status posts, the chain Microsoft described looks like this:

1. A change: first “configuration updates”, later “an earlier network capacity upgrade”.
2. Servers fail their automated health checks and are removed from service.
3. The remaining servers take the load and become overloaded.
4. A core connection process on those servers is overwhelmed.
5. The routing tier retries, which sends a surge of calls to the backend.
6. Servers that are brought back get stuck “in a bad state” again under that retry load.

That last step is why a change that could probably have been rolled back in an hour turned into a 20-hour event. A fleet that is recovering is fragile, and if every client hammers it the moment it comes back, it falls over again. Engineers call this a retry storm. It is the same shape as Amazon’s long recovery after its us-east-1 outage in October 2025.

There is a close precedent at Microsoft itself. In January 2023, an engineer adding capacity to Microsoft’s global WAN changed router IP addresses, the rest of the network recomputed its routes, and Microsoft 365 and Teams went down for about five hours, according to Microsoft’s review at the time. A capacity upgrade is the kind of change that feels safe. It is often the one that isn’t.

Who was hit #

The damage was broad and mostly administrative. It was also very public, because the people who lost email were the people who run things.

• In Australia, ASIO, the domestic intelligence agency, and the Australian Federal Police lost email. Home Affairs Minister Tony Burke said Microsoft did not believe it was a cyber event, and the government activated an agreement with Microsoft for priority restoration.
• In Japan, inter-ministerial communications were disrupted. In Singapore, government agencies, some banks and courts were affected, although GovTech said Singpass, the national login, kept working.
• In the Philippines, the Supreme Court was among the institutions reporting disruption. Courts in New South Wales delayed bail hearings.
• Euronext told listed companies to phone rather than email. Some companies postponed results announcements. Hong Kong’s exchange said trading was normal.
• In the UK, GP surgeries were hit, pharmacies warned of prescription delays, and several police forces asked the public to phone instead of emailing.
• Local newspapers are my favourite detail. LSN News found 19 notices from 19 different local news sites telling readers how to reach the newsroom without email: Newsquest titles in England, Postmedia weeklies in Alberta, a Wyoming daily. One was How to contact the Worcester News. There was even a cluster on estate agents and home movers on Friday the 13th, which is a very British kind of catastrophe.

OpenAI and Anthropic said their Microsoft connectors were broken too, so even the AI tools people reached for to work around the outage depended on it.

What we don’t know is the size of the damage. There is no authoritative count of affected users and no credible loss estimate yet. “Millions” is a press description. The figure of about 430 million Microsoft 365 users is the population at risk, not the number affected.

How the world covered it #

LSN News, my news engine, counted 4,556 articles from 2,272 outlets in 55 languages in the main story by Friday evening. It caught the first articles 44 minutes after the first user reports, from a Brazilian and a Spanish consumer-tech desk, ahead of the big English-language outlets.

Two things stood out. First, the framing was national. Americans asked “Is Outlook down?”, British outlets wrote about councils, trains and GP surgeries, and Spanish, French and Greek titles called it a global failure in the headline. Second, almost no one claimed a cyberattack. Only 44 titles from 36 outlets even raised the idea, under 2% of the story, and most of those reported Microsoft ruling it out. No outlet in the data stated an attack as fact.

Scammers will try anyway. The Isle of Man’s Cyber Security Centre and ING Australia both warned on 13 November about fake “fix” offers and password-reset lures.

Who runs on one vendor #

This was the second or third serious Microsoft 365 disruption of 2026, depending on how you count. Reuters called it the second. Status-page mirrors also record a 31 August to 3 September authentication incident that reportedly lasted 77 to 92 hours. Those two events alone add up to roughly 100 hours of disruption in about ten weeks.

The organisations that went quiet on Thursday were not careless. They chose a reliable, well-run service, and on most days it is. The problem is structural. The intelligence agency, the court, the stock exchange, the GP surgery and the local paper all made the same sensible choice, so they all failed together. For one day, public life in several countries had one shared dependency, and it was a network change inside one company.

Checklist #

• Keep an incident channel that is not the thing that is down. A runbook that says “open a Teams bridge” fails exactly when it is needed.
• Keep an offline contact list for staff, suppliers and regulators.
• Give break-glass accounts a path that does not depend on the identity provider you are trying to reach.
• Add a synthetic probe for each SaaS you depend on, so you hear about the outage before your users tell you.
• Push config and network changes through staged rollout, canaries and fast rollback, the same as code.
• Make clients back off: exponential backoff with jitter and circuit breakers keep a recovering service recovering.
• Brief users now about “re-verify your mailbox” and fake helpdesk lures.

What to watch #

The post-incident review for MO1550821 and EX1550543 is the key document. I will read it for four things: what exactly the network change was, why health checks removed so much capacity at once, whether change review or on-call capacity played a part, and when Microsoft considers the incident formally resolved.

Frequently asked questions #

Was the Microsoft 365 outage a cyberattack? #

No, according to Microsoft and to Australia’s Home Affairs Minister. Microsoft’s wording firmed up over the day, from “no indication” of malicious activity to “not related to cyber or AI/agents”. In the coverage I measured, no outlet stated an attack as fact.

What caused it? #

Microsoft’s preliminary account is an earlier network capacity upgrade that led servers to fail health checks, which overloaded the rest and set off a retry storm. That is Microsoft’s description in status updates. The post-incident review, which should confirm or correct it, was not out as of 13 November.

How long did it last? #

Microsoft dates the impact from 16:17 UTC on 12 November. Outage.com marked it resolved at 14:24 UTC on 13 November, a little over 20 hours. Some customers were still seeing degraded service later on Friday.

Was it caused by high demand? #

No. Microsoft said the elevated load “wasn’t driven by an increase in traffic” but by servers being unexpectedly unavailable. The “high demand” line in a few explainers was a paraphrase error.

What should a small company do differently? #

Mostly cheap things: an out-of-band chat channel, an offline phone list, a break-glass admin account, and a simple external probe on your mail. You probably can’t leave Microsoft 365, but you can make sure its outage is not also your communications outage.

The lesson #

The cloud did what complex systems do: a routine change met a fragile state, and recovery took longer than the failure. That will happen again, at Microsoft or somewhere else. What made this one historic was not the bug but the reach. Convenience at scale is also concentration at scale, and the only part of that you control is how much of your own work stops when someone else’s network change goes wrong.