Back
Microsoft 365 Outage, November 12 2026: Why Outlook, Teams and Exchange Online Went Down
A network change exposed a flaw left behind by an earlier capacity upgrade, health checks started pulling servers out of rotation, and Microsoft 365 spent about a day recovering. Here is what broke, in what order, and what admins should do now.
Jagdish Patil
•
Incident Overview (TL;DR)
What failed: Microsoft 365 connectivity, centered on Exchange Online and Outlook, with wider impact across Teams, SharePoint Online, Microsoft 365 Copilot, Defender, Intune, Planner, To Do and Purview.
When it started: Thursday, November 12, 2026. User reports spiked around 1 p.m. ET (18:00 UTC). Microsoft acknowledged the problem within the hour under incident EX1550543, later tracked alongside MO1550821.
Where: Global. Microsoft said users in any region could be affected. On Friday it described Japan as comparatively stable, Europe and North America recovering, and Asia Pacific showing early recovery signals.
Cause, per Microsoft: An issue introduced during an earlier network capacity upgrade, which surfaced after a more recent network change. Microsoft says it was not a cyberattack and had nothing to do with AI agents.
Status: Resolved, with cleanup ongoing. As of early Saturday, November 14 (UTC), Microsoft reported sustained recovery and email queues approaching normal levels while it keeps watching the message backlog. The full incident report has not been published yet.
Affected Services and User Impact
Microsoft's headline list named nine services: Exchange Online, Microsoft Teams, SharePoint Online, Microsoft Copilot 365, Defender XDR, Planner, To Do, Intune and Defender for Office 365. The status page detail grew well past that as the day went on. Here's how the impact actually showed up.
Email: Exchange Online and Outlook. Users could fail to reach their mailboxes through Outlook on the web, Outlook desktop, Exchange ActiveSync and REST connections. Mail was delayed, not lost. Microsoft extended its email timeout window to 48 hours so messages from outside senders would sit in queues instead of bouncing. Even after sign in recovered, Microsoft warned that mail flow would trail behind while those queues drained.
Collaboration: Teams, SharePoint, Planner and To Do. Teams sat on the impacted list, but a later status summary said most core functions, including joining calls and meetings, group chats and channel messages, were not affected. Some SharePoint Online users hit errors sharing files with people outside their organization. Planner had task reliability problems, and To Do sometimes wouldn't load at all.
Copilot and Microsoft Graph. Copilot Chat could fail to load or respond in the web and desktop apps, and Copilot experiences could lose access to work data. Graph API requests that touch Exchange data, such as mail, calendar and contacts, could time out. That broke Teams management and activity notifications built on Graph. If you run internal automations on Graph, this is the part to check, because a Graph timeout looks exactly like a bug in your own integration.
Security, compliance and devices. Defender portal pages could fail to load. Several Purview services, including DLP, auto labeling, Information Protection and RBAC, were impacted, which delayed some Defender for Office 365 policy evaluation. Intune enrollment, check in and compliance policies were intermittently affected. Some Power BI and Fabric exports involving sensitivity labels failed.
Everything else. Some Microsoft 365 admin center pages wouldn't load. Power Apps mobile sign in failed intermittently, Universal Print jobs threw errors, and Windows 365 Cloud PCs configured with Purview Customer Key could fail to connect.
What about Azure and Entra ID? Microsoft's incident communications were about Microsoft 365. Downdetector did show Azure complaint spikes next to Outlook and Teams, but Downdetector counts user reports, not service health. Windows Central noted that AWS and Cloudflare also appeared to spike, and both companies told the outlet their services were fine. NBC News listed Azure as showing no detected issues during its coverage. We found no Microsoft statement naming Azure or Entra ID as part of the failure.
The human cost was real. Windows Central reported the NHS in the United Kingdom lost email and Teams for most of a working day, and a UK parliamentary spokesperson confirmed fallback arrangements were in place. Anderson Economic Group floated an early estimate of close to $7 billion in lost productivity, which the firm itself called a starting point rather than a final figure.
Technical Breakdown and Root Cause
Microsoft's confirmed explanation, posted with its apology on Friday, November 13, is short: an issue introduced during an earlier network capacity upgrade surfaced after a recent network change. Microsoft says it fixed the underlying issue and then restored service in stages, validating stability at each step, which it acknowledged made recovery slower.
The more useful material is how the symptoms evolved in Microsoft's public updates over the first 12 hours. Times below are approximate UTC, taken from live coverage of Microsoft's status page and its @MSFT365Status account.
About 19:00, November 12: Microsoft reports elevated load on part of its infrastructure across multiple regions and starts redistributing connection traffic worldwide.
About 19:35: All deployments and configuration changes are paused. Microsoft corrects its read of the load: traffic hasn't grown, but a large number of servers are unexpectedly unavailable, so the remaining ones carry their share.
About 20:00: The affected servers are failing automated health checks and dropping out of service. Microsoft restarts all of them while testing a configuration fix.
About 20:37: No recent change correlates with the start of impact yet. The failed checks may come from a specific component on the servers that processes health checks. Microsoft bypasses it on a subset, blocks any more servers from being pulled, and notes elevated processor usage on affected machines.
About 20:49: Many affected servers become fully unresponsive, so Microsoft can't confirm whether the bypass works. More restarts follow.
About 21:30: An alternative health check method works on a subset and starts rolling out wider. Microsoft builds automation to keep detecting and restarting unresponsive servers, and flags a few configuration updates as possible contributors.
About 00:50, November 13: Recovered servers can go unresponsive again as soon as they take traffic, so Microsoft starts limiting which kinds of traffic reach affected infrastructure in some locations.
About 01:48: The clearest technical detail so far. A process on the affected servers that establishes secure connections becomes overwhelmed, and the servers stop processing requests. Microsoft validates a configuration change on a subset and begins reverting a recent network configuration change that correlates with the start of impact.
About 19:00, November 13: The apology lands, naming the earlier capacity upgrade and the later network change as the cause.
Notice that Microsoft said at 20:37 that no recent change correlated with the outage, then reverted a correlating network change about five hours later. That isn't a contradiction worth getting excited about. Early hypotheses during a live incident get revised constantly, and the full report should explain how the trigger was found.
Our reading of the symptoms (interpretation, not confirmed). The pattern looks like a classic capacity cascade. Servers struggle to complete secure connection setup, which is processor heavy work. They start failing health checks, the load balancing layer pulls them out, and the survivors absorb even more connections until they fail too. Restarting doesn't break the loop on its own, because a freshly restarted server rejoins the pool and immediately takes the full backlog of reconnecting clients. That would explain why Microsoft had to stop removing servers, swap the health check method, throttle traffic types and bring load back gradually. It would also explain why recovery took about a day even after the suspect network change was being rolled back on Thursday evening.
What Microsoft hasn't said yet: which network change triggered it, what the capacity upgrade left behind, why the secure connection process became overwhelmed, how many servers were involved, and why regions recovered at different speeds. Expect those answers in the incident report.
Guidance for IT Admins and Users
Service is back for most tenants, but cleanup isn't finished. Here's what's worth doing now, and what's worth not doing.
Get status from the source, in this order.
Service health in the Microsoft 365 admin center, under incidents EX1550543 and MO1550821. This is where tenant specific detail shows up.
status.cloud.microsoft, the public status page, for when the admin center itself won't load. Microsoft pointed users there during this incident.
@MSFT365Status on X for the fastest public updates.
azure.status.microsoft and Azure Service Health if you run Azure workloads and want to rule them in or out.
Don't troubleshoot locally during an upstream outage. Password resets, cache clears, Outlook profile rebuilds and reinstalls do nothing for a server side failure. They also create new work: a rebuilt profile has to resync the whole mailbox, adding load to a service that's still catching up, and every forced reset becomes a helpdesk ticket someone closes later.
Don't mass resend email. Queued messages are still being delivered inside Microsoft's 48 hour window. Resending now just means recipients get duplicates when the backlog clears. If something critical is still missing after Microsoft declares the backlog cleared, run a message trace in the Exchange admin center before asking anyone to send it again.
Audit what failed quietly. Graph based automations, Power Automate flows that read mail or calendars, Purview labeling and DLP actions, and Intune compliance check ins all had documented impact. Any of them could have skipped a run without throwing a visible error. Spot check the ones your business depends on.
Hold your own change window. Microsoft froze its deployments during the incident. Deferring nonurgent tenant configuration changes until the incident report is out keeps you from debugging two problems at once.
Keep your evidence. Save the incident IDs, your own impact timeline and which teams were affected. If your agreement includes service credits, you'll need that record, and Microsoft's report will help support it.
For everyday users: if Outlook works now but some recent mail is missing, give the backlog time before assuming it's gone. And if your company still has no agreed backup channel for when Teams and Outlook are both down, this week is a good time to pick one.
The Monitoring Lesson Hiding in This Outage
For the first stretch of this incident, one of the main ways to confirm Microsoft was down was a status page that Microsoft also hosted, and it struggled to load. Tom's Guide's live blog fell back to X for updates while the status page timed out.
That's the uncomfortable takeaway for anyone running a business on cloud tools. If your alerts arrive by Outlook email or a Teams channel, you'll learn about an Outlook or Teams outage roughly when it ends. Alerting has to live outside the thing it watches.
This is why we built SIOPS around a phone alarm instead of an inbox. When a site or endpoint you monitor stops responding, SIOPS rings a native alarm that bypasses silent mode and Do Not Disturb, and it can also place a call. None of that path runs through your email provider or your chat tool.
One honest limit: an external uptime check confirms whether an endpoint answers. It won't tell you that a Microsoft mailbox loads but can't sync. Point it at what you own, like your client sites, your API and your login pages, and use Microsoft's Service health for Microsoft. The free Hobby plan covers 5 monitors if you want to set that up before the next big one.
We'll update this outage breakdown with the confirmed root cause once Microsoft publishes its full report.
