IT analysts monitor a global cloud email security dashboard displaying service alerts and system health.
Microsoft 365 had a long, messy outage. It ran from Thursday into Friday, and on Friday Microsoft said that changes it had already applied were "not taking as expected." The trouble started with Exchange Online and spread to the services that rely on it. Upstox counted 19 Microsoft services affected, including Outlook, Teams, Copilot and several enterprise and security tools. Microsoft has not given a final root cause or a full restoration time.

IT analysts monitor a global cloud email security dashboard displaying service alerts and system health. The two incident IDs to track​

There are two incident records. Microsoft is tracking the Exchange Online disruption under EX1550543 and the broader Microsoft 365 incident under MO1550821 in the Microsoft 365 admin center. EX1550543 covers mailbox access. MO1550821 covers the other services that depend on Exchange.

Microsoft also described the limits of the impact. Features of many Microsoft 365 services that interact with Exchange Online and email services are impacted. Elements of those services that do not depend on interaction with Exchange Online remain functional, Microsoft said. So "Microsoft 365 is down" isn't quite accurate. More precisely, anything that needs Exchange was having a hard time.

Section summary: Use EX1550543 for mailbox problems and MO1550821 for everything else. Features that don't depend on Exchange mostly kept working.

Timeline​

The outage started in one region and then spread. Microsoft initially reported that users in the Americas were having trouble connecting to Exchange Online mailboxes. It later identified potential disruption to Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR. While the company initially reported Exchange Online connectivity problems in the Americas, it later confirmed that users in any region could be affected.

LazyAdmin, a Microsoft 365 admin blog, built a UTC timeline from Microsoft's posts. Its key entries:

Time (UTC)Event
Thu 14:45–15:53Separate Teams incident (TM1550488), Americas only. Resolved.
Thu 16:17EX1550543 starts. Users can't open their mailboxes.
Thu 18:26MO1550821 opened for the services that depend on Exchange Online.
Thu ~19:06Microsoft pauses all deployments and configuration changes.
Thu ~21:08Some servers return to service using a different health check method.
Fri 00:00Returned servers become unresponsive again once they receive traffic.
Fri 01:50Restarts show positive results; the fix is to be expanded.
Fri 04:57Microsoft scales up VMs to handle the traffic surge. Some machines are stuck in a bad state.

The Teams incident on Thursday morning (TM1550488) had its own ID and was resolved before the Exchange problem began. If you're putting together an incident report or an SLA claim, list it separately.

What Microsoft said went wrong​

Microsoft's explanation changed over the course of the incident.

At first, Microsoft pointed to capacity. According to Upstox, the Microsoft 365 Status account on X said the elevated load wasn't caused by more traffic. Instead, servers had become unavailable unexpectedly, which put extra strain on the rest of the infrastructure. In an earlier status post quoted on Microsoft's Q&A forum, the company said it was testing a configuration change to address a problem that's causing servers to fail automated health checks and become unavailable.

The update that seems most useful for root cause came later. The University of Pennsylvania's PennO365 alerts page, which copies Microsoft's service health text, carries the passage. Microsoft said a process on the affected servers that handles secure connections was getting overwhelmed, and the servers then stopped processing requests. Microsoft said it was testing a configuration change on a subset of servers before rolling it out more widely, along with restarts. It also said it had started reverting a recent network configuration change that correlates with the start of impact.

Don't skip over the word "correlates." An earlier update on the same feed said Microsoft hadn't found any recent changes that lined up with the start of impact. That update blamed a component that processes health checks on the affected servers and noted high processor usage. Upstox reported the same thing: Microsoft had not found a recent change that coincided with the start of the outage. So did a network change cause this? The available sources don't say. A rollback that lines up in time is something to look into. It isn't a confirmed cause.

Microsoft has ruled one thing out. According to WindowsForum's megathread, Microsoft executive Charles Lamanna also said there was no indication the outage resulted from malicious or cyber activity.

Section summary: Microsoft has gone from "servers failing health checks" to "a secure-connection process getting overwhelmed," and it is reverting a network change it can only say correlates with the outage. There's no confirmed root cause yet.

Why the fixes haven't held​

Upstox reported several recovery steps: restarting servers, moving traffic onto other parts of Microsoft's global network, adding compute capacity and scaling up virtual machines. Some servers came back and then stopped responding as soon as they got traffic again. Microsoft then went through diagnostic data and temporarily limited some kinds of traffic.

The PennO365 copy shows those traffic limits were in place in specific locations. Microsoft planned to watch whether servers stayed stable with fewer connections before slowly adding traffic back. Upstox also quoted Microsoft saying that partial recovery in adjusted regions wasn't lasting. It said too that Microsoft was trying to force recent network changes to sync on machines stuck in a bad state.

If you've worked in operations, you know this pattern. Fix a server, send it traffic, and it falls over again. That usually means more than a simple capacity shortfall, and it explains why the outage ran into a second day.

Service-by-service impact​

Upstox counted 19 affected products, based on Microsoft's impact list:

  • Exchange Online: Mailboxes may not open in Outlook on the web, desktop apps or other connections. Email may be delayed.
  • Microsoft 365 admin center: Some pages may not load.
  • Microsoft 365 apps: Recently used files may not show up.
  • Microsoft 365 Apps Admin Center: Cloud Update, Cloud Policy and Inventory are affected.
  • Microsoft 365 Education: Assignments, Reading Progress and Speaker Progress may not work.
  • Microsoft 365 Copilot: Copilot Chat may not load or respond, and Copilot may not be able to reach work email, calendar and files.
  • Defender for Office 365: Safe Links, Safe Attachments, Quarantine and Threat Explorer may fail.
  • Defender XDR: Some portal pages and solution tabs may not load.
  • Microsoft Fabric: Exporting reports to PDF or PowerPoint, or opening protected files, may fail.
  • Microsoft Graph: Mail, calendar and contacts requests may time out.
  • Intune: Device enrollment, check-ins and compliance policy operations may fail at times.
  • Planner: Plan and task operations are unreliable.
  • Purview: Data protection, compliance and classification features are affected.
  • Teams: Calls, meetings, group chats and channel messages mostly work. Calendar, scheduling and invites may fail.
  • To Do: The app may not load or may throw errors.
  • Power BI: Exporting reports with certain sensitivity labels to PDF may fail at times.
  • SharePoint Online: Features that depend on Exchange may be affected, but you can still open stored files directly.
  • Universal Print: Submitting print jobs and using admin features may produce errors.
  • Windows 365: Some tenants using Microsoft Purview Customer Key may not be able to connect to Cloud PCs.

The PennO365 copy of Microsoft's text adds detail Windows admins should know:

  • Safe Links failures block navigation. Clicking a wrapped or rewritten URL fails because Safe Links can't process it. Users who do reach Quarantine may still be unable to release messages. Tenant Allow/Block list changes, message traces and reporting may be delayed.
  • Power Apps mobile sign-in may fail on and off for Power Apps and Field Service. Microsoft suggested using the web versions instead. It also said users who are already signed in should not sign out, clear app data or reinstall until the issue is fixed.
  • Teams edge cases go further than calendar problems. Live and virtual events may not be created, private or shared channels may not be created or deleted, contact sync may fail, and chat creation may fail in tenants that use Information Barriers.
  • Purview also listed audit searches, eDiscovery search and export, and On Demand Scan among the possibly affected features.

Section summary: A failure in Exchange reached security tooling (Safe Links, Defender XDR), compliance (Purview, eDiscovery), device management (Intune) and even Cloud PC access. That's why this outage matters well beyond email.

What admins should do now​

  1. Watch the right records. Microsoft's Q&A guidance says to sign in to the Microsoft 365 Admin Center. Go to Health > Service Health. Search for Issue ID: MO1550821. Check EX1550543 for mailbox status. If the admin center won't load, Microsoft posts the same updates on status.cloud.microsoft and on the @MSFT365Status account on X.
  2. Check the service list again. WindowsForum's earlier coverage pointed out that Microsoft has updated the affected-services list in the MO1550821 "more info" section, so yesterday's version may be out of date.
  3. Don't troubleshoot your PCs. This is a server-side problem. Repairing Outlook profiles or reinstalling clients won't fix it, and for Power Apps mobile Microsoft specifically says not to.
  4. Tell users about Safe Links. A link that won't open isn't necessarily malicious. Users should still be careful, though. Coverage has advised admins to warn users about phishing emails and fake support calls that exploit the outage.
  5. Record what happened for SLA credits. Windows Latest reports that you have to request a credit yourself. In the support request, explain that you want Microsoft to review an SLA credit for the outage, and include the relevant incident ID, such as EX1550543 for Exchange Online or MO1550821 for the broader Microsoft 365 incident. Whether you qualify depends on your agreement and how much your tenant was actually affected. Opening a request doesn't mean you'll get money back.

Analysis: when one service takes down the rest​

Ask yourself how many of your tools depend on Exchange Online. Before Thursday, most admins would have said Outlook and the calendar. This outage showed the list is much longer: Copilot's access to work data, Teams scheduling, Purview DLP, Safe Links and, for Customer Key tenants, Windows 365 Cloud PCs.

To be fair to Microsoft, the company kept clearly separating features that were broken from features that still worked, and Teams calls and chats kept working. On the other hand, the recovery has gone badly. Fixes failed, servers relapsed, and the explanation went from "nothing correlates" to "a network change correlates." Microsoft owes customers a detailed post-incident review that explains what caused this, not just what lined up with it in time.

For now, document your impact, keep an eye on both incident IDs, and stay skeptical of any root-cause claim until Microsoft publishes its review.

 

References

  1. Microsoft struggles to restore services: What actually happened and list of services affected - Upstox Upstox 2026-11-13T06:19:31+00:00
  2. Microsoft 365 Outage - Current Status and SLA Credits — LazyAdmin lazyadmin.nl
  3. Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams - SecurityWeek securityweek.com