Microsoft 365 spent the back half of Thursday, and all of Friday morning in Asia, failing in public. An Exchange Online incident (EX1550543) opened at 16:17 UTC on November 12, a suite-wide one (MO1550821) followed at 18:26, and at 07:25 UTC on Friday, the latest update we could verify, Microsoft still reported only partial recovery after more than 15 hours. For anyone whose sign-in codes, alert emails and incident bridge all live in one tenant, it was an architecture review delivered at full price.
Fifteen hours, in UTC
The prelude was a North American Teams incident, TM1550488, resolved within the afternoon (UC Today and IT-Connect disagree on its times). Then Exchange went. Mailbox access failed across Outlook on the web, MAPI, ActiveSync and REST, per a University of Pennsylvania mirror. At 17:54 Microsoft placed the impact in the Americas; at 18:07 it said users in any region could be affected.
The suite incident's list kept growing: Teams, SharePoint Online, Copilot, Defender XDR, Defender for Office 365, Intune, Purview, Power BI and Universal Print among them, per a third-party mirror of Microsoft's feed. Dynamics 365 contact-center agents were locked out for just under eight hours, until 00:57 UTC. Azure's public status page showed no Azure issues throughout.
Downdetector, which counts user reports, not affected users, logged reports from 74 countries and territories in about an hour and roughly 130,000 Outlook reports shortly after 18:00 UTC. ABC News in Australia cited the US tracker at more than 120,000 for Outlook and more than 45,000 for Microsoft 365.
The consequences were less abstract. Japan's government fell back to paper, Hong Kong bankers at Morgan Stanley and Goldman Sachs lost email and Teams for the day, and Australia's spy agency and federal police were among those hit.
The health checks became the blast radius
Microsoft's first theory was traffic: updates described "elevated load across multiple regions" (Penn mirror). By 19:18 UTC it had reversed itself: traffic had not increased; a large number of servers were "failing automated health checks" (SecurityWeek) and dropping out, pushing their share onto the survivors. All deployments and configuration changes had been paused at 19:06.
The telling moves came next. At 19:58 Microsoft was blocking servers from removal and bypassing the component that processes health checks, and reported no change correlated with the onset (Cloud Admin Hub mirror). At 20:57 an alternative health-check method worked on a subset. By 22:03 the diagnosis had narrowed to an overwhelmed core process, later described as the one that establishes secure connections. Then the cruel part: repaired servers stayed healthy until they were useful. Microsoft warned they "can become unresponsive again once they begin receiving traffic" (ABC News).
At 01:12 UTC on Friday, about five hours after saying nothing correlated, Microsoft began rolling back "a recent network configuration change" that coincided with the start of impact. At 04:10 it reported partial recovery "not resulting in sustained recovery"; at 05:01 its mitigations had triggered a surge of calls from routing services to backends; at 07:25 it reported improving server stability after patching part of the fleet. Root cause still reads N/A on both incidents, and Microsoft has said a root-cause report will follow once the incident is contained.
Not an attack, but not harmless to security
Microsoft's Charles Lamanna wrote that "there is no indication this is the result of malicious or cyber activity" (The Next Web). Australia's cyber minister, Tony Burke, likened it to the 2024 CrowdStrike episode, "an update that has gone awry" (Al Jazeera). That analogy is his; Microsoft has named no faulty update.
The outage still dulled defenses. Safe Links and quarantine release could fail and message trace lagged (IT-Connect); Defender XDR portal trouble could block access to alerts, though portal problems alone do not mean endpoint protection stopped (Cybersecurity News). Standard Chartered and ING Australia warned of scammers posing as tech support; the University of Illinois reminded users that IT never asks for passwords.
What to change before the next one
Treat your health checks as load-bearing. Microsoft's first stabilizing act was stopping its checker from evicting more servers. If a check can remove capacity faster than you can add it, cap how much of a pool it may eject and page when the cap is hit; return repaired capacity behind admission control, because the backlog is waiting at the door.
Do not learn about a vendor incident from your users. Service health in the admin center needs a role such as Service Support admin; when the admin center is down, Microsoft points to status.cloud.microsoft and @MSFT365Status (Microsoft Learn). The mirrors that tracked this incident poll Microsoft's Service Communications API every 60 seconds; your pager can listen to the same feed.
Map what silently needs Exchange: reset mail, one-time codes, alerting, the incident bridge in Teams. OpenAI and Anthropic both reported their Microsoft 365 connectors failing (ABC News); your SaaS vendors inherit Microsoft's bad day too. Credits, if you pursue them, run through the Service Level Agreement for Microsoft Online Services, current edition dated November 1, 2026.
What we could not verify
- Full recovery. Unconfirmed; our timeline stops at 07:25 UTC Friday, so every duration here is a floor.
- Root cause. The rolled-back network change correlates with the onset; Microsoft has not called it the cause and no post-incident review exists. A different finding would change the story, not the health-check lessons.
- Primary pages. We could not load status.cloud.microsoft or Microsoft's X posts; timestamps come from mirrors and outlet logs of Microsoft's text.
- SLA tiers. We did not open the agreement text, so we quote no credit percentages.
- Downdetector. Crowdsourced and from different snapshots; the 130,000 and 120,000 figures are not comparable.
The 30,000-foot read
The shape is familiar to anyone who has run a fleet: a partial failure, a health checker doing its job too well, survivors overwhelmed, and repaired servers flattened by the traffic they were repaired to serve. The network rollback may prove to be the root, or only the first lever that moved; the review, not a guess, will say which.
What sits in your control is narrow. Know which systems need Exchange to be up in order to tell you Exchange is down. Put the status feed where your pager can hear it. Keep one channel that lives somewhere else. Microsoft will publish its review; the better question is how long yours would have been.
Sources: UC Today (UTC timeline of Microsoft's status updates, TM1550488, Dynamics 365 lockout, 15-hour duration, Azure status, partial-recovery quote); SecurityWeek (incident IDs, health-check explanation, traffic not increased); Cloud Admin Hub (third-party mirror of MO1550821 updates and affected-service list, 60-second API polling); University of Pennsylvania (mirrored EX1550543 text and protocols affected); IT-Connect (01:12 UTC network-change rollback, secure-connection process, Defender for Office 365 impact, root-cause report promise, alternate Teams times); ABC News (Australia) (Downdetector US figures, recurrence warning, connector failures); Al Jazeera (Outlook report peak, Australian agencies, Burke's comparison); The Next Web (74 countries, Lamanna statement, Japan, Hong Kong banks, scam warnings); Cybersecurity News (incident IDs and services, Defender XDR portal caveat); University of Illinois Technology Services (password reminder); Microsoft Learn (Service health roles, status page and X fallback); Microsoft Licensing (SLA edition date). CAVEAT: no primary Microsoft status page could be loaded; Microsoft's update text is taken from third-party mirrors and outlet logs, and Lamanna's quote is as reported by The Next Web. Downdetector figures are crowdsourced and third-party. The outage was unresolved at the last verified update (07:25 UTC, November 13). The October 2025 Azure Front Door outage is not discussed because we did not verify it in this session.