State of play as of 14 November 2026. Incidents EX1550543 and MO1550821 were still open with no published root cause at the last check — go to Service health in the Microsoft 365 admin center for the current state, not this page.
The Microsoft 365 outage that began on 12 November took down far more than email. Defender for Office 365, Purview DLP and eDiscovery, Copilot, and Teams calendar invites all degraded alongside it, because every one of them reads from Exchange Online.
That single dependency explains why "Microsoft 365 is down" and "Teams is working fine" were both true on the same afternoon. A group chat worked. A calendar invite didn't.
What Microsoft actually said, in order
The explanation changed four times, and the sequence matters more than any single statement:
- Elevated load across multiple regions — then clarified that the load came from servers being unexpectedly unavailable rather than from a traffic increase. Lost capacity under normal demand, which is the opposite shape to a denial-of-service attack.
- Servers failing automated health checks, possibly from a specific component processing those checks. Microsoft paused all deployments and configuration changes while investigating.
- A process that establishes secure connections becoming overwhelmed on the remaining servers, so they stopped handling requests too.
- A recent network configuration change that correlates with the start of impact, which Microsoft began reverting overnight. This one is a reversal: at 19:57 UTC it had said it identified no recent change correlated with the start. "Correlates" is not "caused." The incident record still shows Root Cause: N/A, and anything naming a definite cause right now is ahead of the post-incident report.
Microsoft has said repeatedly it is not aware of malicious activity causing the incident. That's a statement about current knowledge, not a closed finding.
Timeline
| Time (UTC) | Event |
|---|---|
| Nov 12, 14:45–15:53 | A separate Teams incident, TM1550488, hits users in the Americas — delayed and failed chats, presence delays. Preliminary cause given as resource contention. Resolved before the Exchange problems begin. |
| Nov 12, 16:17 | EX1550543 opens: users may be unable to connect to Exchange Online mailboxes through multiple methods. |
| Nov 12, ~18:45–19:00 | Redistributing connection traffic, pausing deployments, restarting affected servers. |
| Nov 12, 19:50 | Testing a configuration change for servers failing automated health checks. |
| Nov 12, ~21:00 | An alternative health check returns a subset of servers; automated recovery prepared. |
| Nov 12, 22:11 | Microsoft says its actions have not provided the relief it expected. |
| Nov 12, evening | Returned servers become unresponsive again under traffic; some traffic types limited. |
| Nov 13, 06:12 | Still recovering frontend servers while applying traffic optimization. |
| Nov 13, 12:30 | Progress reported, intermittent issues may continue. Recovering, not resolved. |
Worth separating TM1550488 from EX1550543. A lot of coverage merged the morning Teams incident into the Exchange one; Microsoft has not said the two are linked, and the Teams incident was marked resolved before Exchange degraded.
What broke and what didn't
| Affected | Mostly unaffected |
|---|---|
| Outlook web, desktop (MAPI), ActiveSync, REST; delayed mail delivery | Teams core calls, meetings, group chats, channel messages |
| Microsoft Graph requests touching mail, calendar, contacts | Files stored directly in SharePoint Online |
| Teams calendar, event creation, contacts | Workloads with no Exchange Online dependency |
| Copilot; Defender for Office 365 and Defender XDR portals; Purview labeling, DLP, audit, eDiscovery; Planner; To Do; admin center pages; selected Intune, Fabric, Power BI, SharePoint, Universal Print and Windows 365 scenarios |
One operational detail worth knowing if you're reconciling now: delayed mail was being protected with a 48-hour retry window. Check what landed late rather than assuming it was lost.
The business consequences landed where email is a control rather than a convenience — a public company delayed an earnings release, and a county sheriff's office took bond payments in person. The "450 million users" figure circulating in coverage is Microsoft's user base, not an affected count, and Downdetector's ~130,000 Outlook reports are user reports, not confirmed affected users.
What to do during an active SaaS outage
Triage. Service health in the admin center is tenant-specific; the public status page is the fallback when admins can't sign in. Compare symptoms across users, networks and clients. Capture your own error details and timestamps for reconciliation and any SLA conversation. Hold off on mass reinstalls, profile rebuilds and credential resets — during a confirmed platform incident they fix nothing, add helpdesk load, and risk local state.
Communications. One named incident owner who decides what gets delayed and who gets told. Move operational comms to a channel that doesn't depend on Exchange Online — in this incident, Teams chat was up while mail and invites weren't. Publish on a fixed interval, each update carrying the Microsoft timestamp you're relying on. And flag phishing explicitly: outage confusion invites mailbox-migration lures, and Defender Safe Links was on the affected list.
Manual fallback. List the flows where email gates something — approvals, regulatory notifications, customer SLAs, disclosure comms, payment confirmations — and assign a manual path for each. Decide which automated jobs pause, because anything sending through Graph or an SMTP relay will queue, retry or fail. Log every workaround with who and when, then reconcile duplicates afterwards, especially approvals actioned twice.
The architecture lesson, without overreacting
Map the dependency before you buy redundancy for it. Most teams know email depends on Exchange Online. Fewer know their security tooling and meeting scheduling do. The first deliverable here is a dependency map, not a vendor change: every integration calling Graph for mail, calendar or contacts, every workflow that gates on an email arriving, every alert routed through Exchange.
On concentration risk, the honest answer is selective. A second email platform in parallel adds cost, another identity and security surface, data-governance questions, and reconciliation work after every incident. For most mid-market companies that trade is bad for mail overall and good for a narrow set of flows — status communications, on-call paging, and regulatory notifications deserve a provider-independent path. The rest need better runbooks.
Two things that turn a silent failure into a managed one: workflows that merely notify by email should keep working when email is gone, and workflows that gate on email should fail loudly and route to a human. Visible queues, circuit breakers on Graph calls, explicit timeouts.
And rehearse recovery, because Microsoft's own was unstable — returned servers became unresponsive again under traffic. Tabletop a 14-hour Exchange Online degradation including the reconciliation work, which is the part that gets skipped.
What to watch for next
Microsoft's service description promises a preliminary report within 48 hours of resolution and a final one within five business days for incidents affecting a large number of organizations. That's stated policy rather than a prediction for this case.
Three answers worth waiting for, each of which maps to a question about your own platform:
- Whether the network configuration change Microsoft reverted was the initiating defect or a coincidence.
- Why automated health checks removed capacity faster than recovery could restore it.
- What changes about deployment pausing and traffic shaping as a result. Full write-up — the complete timeline with sources, affected-service breakdown, and the response checklist: teamvoy.com/blog/microsoft-outlook-outage
Written by Teamvoy. More engineering writing at teamvoy.com/blog.
Top comments (0)