Microsoft 365 Outage: Server Health Checks, Network Rollback and an Unconfirmed Root Cause

This is still an active incident, not a story about a finished recovery. Here is what is confirmed, what is still uncertain, and what IT admins should be doing.

The incident IDs to follow​

Microsoft is tracking this under two linked records. In a Microsoft 365 admin center advisory, tracked as MO1550821, Microsoft confirmed that customers may be unable to connect to multiple services, including Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot, and Microsoft Defender XDR. The mailbox side is tracked as EX1550543. For that incident, potentially impacted connection methods may include Outlook on the web, Messaging API (MAPI), Exchange ActiveSync (EAS) and the REST API. Taken together, that means browser, desktop, mobile and API-based mail access could all be affected.

There was also a third, earlier incident. Per BleepingComputer, while the company initially reported Exchange Online connectivity problems in the Americas, it later confirmed that users in any region could be affected. The outage follows a separate Microsoft Teams incident earlier Thursday that caused an outage for users in North and South America. LazyAdmin's timeline lists that earlier problem as a separate Teams incident (TM1550488), Americas only, running from 14:45 to 15:53 UTC on Thursday. Reuters reported that Microsoft had called that Teams issue fully resolved before saying connectivity problems could also hit other regions.

Admin IDs at a glance:

Why an "Outlook outage" broke Teams, Copilot and Defender​

Many people were confused that problems with email also took down meeting scheduling and security portals. The explanation is Microsoft 365's architecture: Exchange Online is the base layer for much of the suite. LazyAdmin put it this way: the incident took a lot more than Outlook with it: Teams calendars, Copilot, Safe Links, Purview and parts of Defender all depend on Exchange.

Microsoft's own impact notes, as recorded in the University of Pennsylvania's mirror of the incident feed, give the details:

• Teams: Most core features, including calls, meetings, group chats and channel messages, were listed as not affected. Anything that relies on Exchange Online, such as scheduling, invites and meeting edits, could fail. Creating Live or Virtual events could also fail, as could creating or deleting private and shared channels.
• Copilot: Users might not be able to load Copilot Chat or get responses in the web and desktop apps. Copilot might also be unable to reach work data such as email, calendar and files.
• Defender for Office 365: Safe Links may be unable to verify URLs, which may impact users clicking links in Outlook and Teams. Microsoft also listed possible failures with Quarantine, Threat Explorer and releasing quarantined items.
• Purview: DLP, auto-labeling, Communication Compliance, eDiscovery search and export, and audit searches could all be affected.
• Windows 365: Tenants that use Purview Customer Key for Cloud PCs might find users unable to connect to their Cloud PCs.

The BBC said messaging and online meetings kept working. Microsoft's own notes broadly agree, but that is a general picture, not a promise. Calendar-related Teams functions were clearly affected, so check your own tenant before telling users what works and what doesn't.

Section summary: If your workflow touches a mailbox, a calendar or a link scanned by Safe Links, it may have been affected, even if the app you were using wasn't called Outlook.

A timeline of fixes that didn't hold​

Microsoft's explanation of the cause changed several times overnight, so it's worth looking at the sequence:

1. Thursday ~19:06 UTC: LazyAdmin's timeline notes that Microsoft pauses all deployments and configuration changes. Microsoft said the high load was not caused by more traffic overall. It said large numbers of servers were unexpectedly going offline, pushing their load onto the servers still running. This is the "elevated load" explanation the BBC reported.
2. 19:43 UTC: Microsoft said affected servers were failing automated health checks. It said this "may be related" to a recent change to a component involved in those checks.
3. 19:57 UTC: In the next update, Microsoft said it had not found any recent changes that matched the start of the problem. It began testing a change to bypass the component that processes health checks, and said it was investigating high CPU usage on the affected servers.
4. Friday 01:06 UTC: Microsoft said a process responsible for setting up secure connections was getting overwhelmed, which stopped servers from handling requests. It also started reverting a recent network configuration change that "correlates with the start of impact."
5. 01:45 UTC: Restarting affected infrastructure produced positive results.
6. 02:54 UTC: Those changes were "not taking as expected." The BBC also reported that Microsoft admitted its attempted fixes weren't working.
7. 04:57 UTC: According to LazyAdmin, Microsoft scales up VMs to handle the traffic surge.

Notice the contradiction between step 3 and step 4. In one update Microsoft said no recent changes matched the start of the outage. A few hours later it was rolling back a network change that did. That isn't necessarily bad faith. It's what root-cause analysis looks like under pressure. But it means any root-cause statement so far is a working hypothesis. Microsoft has said it will publish full details in a Post-Incident Report once the problem is mitigated. Until then, neither "it was a config change" nor "it was a traffic surge" is a final answer.

On Friday morning, the BBC reported that Microsoft had seen only "marginal success" and was still monitoring regions to judge server status and add capacity. It also warned that restored services could fail again. LazyAdmin described Outlook and Exchange Online are slowly recovering, which fits that cautious tone.

Was it a cyberattack?​

According to the BBC, there is currently no evidence of an attack. Microsoft's incident record says it is not aware of any malicious activity causing the incident. CyberPress also noted that Microsoft's public updates describe infrastructure failure and recovery work. They do not present evidence of a confirmed cyberattack behind the disruption. This is Microsoft's own assessment, not an independent forensic finding. Still, nothing published so far points to an attacker.

How big was it? Treat the numbers carefully​

The headline figures come from Downdetector, which counts user-submitted problem reports, not verified affected accounts. The BBC cited at least 140,000 Outlook reports by 18:00 GMT on Thursday. Reuters counted more than 97,000 Outlook reports at 2:07 p.m. ET, plus over 38,000 for Microsoft 365 and about 4,500 for Teams, and noted that the real number of affected users may be different. AP later reported about 130,000 Outlook reports from dozens of countries. The figures were taken at different times and don't quite agree, so read them as a sign of scale, not a census. BleepingComputer said complaints also mentioned Azure, OneDrive, and the Microsoft Store. Those are user reports, not Microsoft confirmations.

Real-world fallout​

The effects went well beyond missed meeting invites:

• Governments and courts: AP reported that Singapore's government technology agency said government email was down. The Philippines' Supreme Court said some operations, including email responses, were affected. Japanese authorities said they had arranged alternatives such as telephone communications.
• Airlines: AP reported that Indian airlines saw email-support disruption but said flight operations were not affected.
• AI companies: Reuters reported that OpenAI was investigating broken Microsoft connectors and that Anthropic traced its Microsoft 365 connector problem to an upstream provider. Their own platforms weren't the source of the failure. Their integrations simply depend on Microsoft 365.
• Corporate reporting: The BBC reported that Workhorse Group moved its third-quarter results from November 12 to November 16, citing business disruption from the outage.

Security researcher Troy Hunt told the BBC that Microsoft is a huge part of the internet's backbone and that the outage shows how important email still is. He pointed out that email is also used for appointment communications, purchase verification and account access. Paul Spain of Gorilla Technology told the BBC that companies had effectively lost a business day.

The BBC also noted that Microsoft reported an Azure outage last month, so this is not a one-off for the company. It's reasonable to ask how many single points of failure sit under Microsoft 365's distributed design. The post-incident report is where Microsoft should answer that.

What admins and users should do now​

None of the steps below is a Microsoft instruction specific to this incident. They are standard practice during a vendor-side outage.

1. Check Service Health first. In the Microsoft 365 admin center, go to Health > Service health and look up EX1550543 and MO1550821 (and TM1550488 if you were affected Thursday). The tenant view may show details the public feed doesn't.
2. Use the fallbacks if the admin center won't load. LazyAdmin notes that Microsoft posts the same updates on status.cloud.microsoft and on the @MSFT365Status account on X.
3. Don't troubleshoot a problem that isn't yours. If users are reporting the symptoms above, resist resetting profiles, rebuilding OSTs or changing mail routing. Hold off on risky account or security changes too. Microsoft notes that on-premises mail flow to or from Exchange Online can also be affected, so hybrid shops shouldn't assume their own servers are at fault.
4. Warn users about Safe Links failures. If rewritten links won't open, that may be the outage. It's not a reason to disable protection.
5. Switch to an alternate communication channel you've already approved, such as phone or another sanctioned platform, for anything time-critical.
6. Expect relapses. Microsoft has said that restored services may fail again. Don't close internal tickets just because one mailbox came back.
7. Keep records for SLA credit claims. LazyAdmin's guide covers how to claim your SLA credit, and suggests noting the incident IDs along with your own timestamps of impact.

The bottom line​

The outage started with Exchange connectivity and spread to scheduling, AI assistants and security tools across Microsoft 365. Microsoft has paused deployments, rolled back a suspect network change, restarted and scaled up infrastructure, and still describes recovery as partial. Until the post-incident report is published, the cause is unconfirmed and Microsoft says it has seen no sign of malicious activity. For admins, the clearest lesson is about dependencies: if your communication, compliance and Copilot workflows all rely on one mailbox service, a single Exchange Online failure can take all of them down together.