Microsoft 365 outage (MO1550821): what happened and what admins should do
Mihai Marangoci, Gociux · 13 Nov 2026 · Updated 13 Nov 2026 · 6 min read
TL;DR
Since about 18:26 UTC on 12 November (20:26 Romanian time), users worldwide may be unable to connect to Exchange Online, Teams, SharePoint, Copilot, Intune, Purview and the Defender portals. Microsoft tracks it as MO1550821, with Exchange under EX1550543.
Microsoft says servers are failing health checks and dropping out, so the remaining ones overload. A process that sets up secure connections gets overwhelmed. Microsoft has seen no sign of an attack.
Update, 13 Nov, about 10:00 UTC: after overnight fixes failed to hold, Microsoft is rolling out a patch to an upstream authentication and routing configuration component and reports "early stabilization". Capacity is not back to normal and there is no time for full restoration.
Don't change your tenant to "fix" it. Move urgent communication to your backup channel, warn users about outage-themed phishing, and log the incident for NIS2 or DORA.
Microsoft 365 is in a multi-region service degradation, tracked as MO1550821: "Users may be unable to connect to multiple Microsoft 365 services." It started at about 18:26 UTC on 12 November 2026 (20:26 Romanian time). By about 10:00 UTC on 13 November Microsoft reported early stabilisation after a patch, but said service capacity "has not yet returned to normal levels" and gave no time for full restoration. The fault is on Microsoft's side, so nothing you change in your tenant or on user devices will bring service back. Your job right now is communication, security hygiene and record-keeping.
Latest update (13 Nov 2026)
The patch: overnight server restarts and rebuilds didn't hold. Microsoft then applied a patch to an upstream authentication and routing configuration component. It is rolling it out region by region, starting with regions entering business hours, and expanding to other services after monitoring (Windows Forum).
09:16 UTC: Microsoft reported "positive results for server stability" from the patch.
09:52 UTC: Microsoft reported "early stabilization and capacity improvements". Service health still said capacity "has not yet returned to normal levels" (TechRadar live).
Email: Microsoft is extending the email timeout window to 48 hours, so delayed inbound mail should still be delivered rather than bounced.
Cause: still no confirmed root cause. Microsoft repeats that it is "not aware of any malicious activity".
Practical meaning: expect uneven recovery through Friday, with some users back and others still failing, and a backlog of mail arriving late. Don't treat the first users who reconnect as the all-clear. If you're weighing a service credit claim, record your impact now (how SLA credits work).
What is affected
Microsoft's list of potentially affected services grew through the night. It now includes:
Exchange Online: Outlook on the web, desktop, mobile and API access, plus delayed mail delivery.
Microsoft Teams: calendar and meeting scheduling. Microsoft said core messaging and meetings were largely working.
SharePoint Online: features that rely on Exchange. Direct file access was reported to work.
Copilot, Planner, To Do and Microsoft Graph: Graph calls time out.
Security and management: Defender XDR, Defender for Office 365 (Safe Links), Intune, Purview (DLP, auto-labelling, data classification, communication compliance) and the Microsoft 365 admin center.
Edge cases: Universal Print. Windows 365 Cloud PCs for tenants that use Purview Customer Key.
Not every tenant is hit the same way. Users at the same company can see different symptoms depending on which servers their connections land on.
What Microsoft says is causing it
Microsoft's first update blamed elevated load across several regions. It then corrected itself: the load "isn't driven by an increase in traffic". Instead, a number of servers became unexpectedly unavailable, which strained the infrastructure that was left. Those servers were failing automated health checks and being pulled from service.
Over the night, Microsoft:
paused all deployments and configuration changes
redistributed connection traffic globally
bypassed a health-check component on some servers
restarted and rebuilt servers, some on a previous software configuration
started reverting a recent network configuration change that coincided with the start of the impact
Microsoft narrowed the fault to a core process on the affected servers, the one "responsible for establishing secure connections". That process becomes overwhelmed, and servers returned to service can stop responding again once traffic reaches them. Its latest updates we read describe a surge in calls from routing services to backend servers, caused by the traffic rebalancing itself. Microsoft is adding virtual machines and force-syncing machines stuck in a bad state.
Microsoft has not published a root cause and says there is no indication of malicious activity. Expect a post-incident report in Service health once the incident is closed.
What to do now
Follow the incident where Microsoft publishes it. Go to Microsoft 365 admin center → Health → Service health and open MO1550821 and EX1550543. If the admin center itself fails to load, use Microsoft's public status page at status.cloud.microsoft. Note the incident IDs and times in your own ticket.
Don't change your tenant. Resetting passwords, rebuilding Outlook profiles, reinstalling Office, or loosening Conditional Access or MFA to "get people in" won't fix a server-side capacity problem. It does create cleanup work and real security gaps. Leave DNS and MX records alone too.
Move urgent communication to the backup channel. This is what your out-of-band channel is for: phone tree, SMS, or a chat tool that doesn't depend on Microsoft 365. If your on-call alerting or incident bridge runs only on Teams and Outlook, today shows that gap. Tell users in one short message that mail may be delayed, that Microsoft is working on it, and that they shouldn't try local fixes.
Expect delayed mail, not lost mail, but verify. Sending mail servers normally queue messages and retry when the receiving side is unavailable. After recovery, check message trace for queued or failed deliveries on business-critical flows (invoices, payment notifications, regulator correspondence) and confirm with key senders.
Warn users about outage-themed phishing. A global outage is a perfect lure: fake "restore your mailbox" or "re-verify your account" emails and texts with sign-in links. Safe Links is on the affected list, so link protection may not behave normally right now. A one-line warning to users is worth sending today.
Keep watching security from other angles. Not being able to reach the Defender portal doesn't mean endpoint protection on devices has stopped. Microsoft Defender Antivirus still runs locally. What you lose is visibility and cloud-driven response. If you forward alerts to a SIEM, watch them there. When the portals come back, review the alert queue and sign-in logs for the outage window.
The compliance side: NIS2 and DORA
An outage at your cloud provider is still an incident in your own register.
DORA: financial entities "shall record all ICT-related incidents and significant cyber threats" (DORA Article 17(2)). Classify this one against your criteria: affected clients and services, duration, critical functions. If it meets the major-incident thresholds for you, the reporting clock applies even though the cause sits at a third party.
NIS2: under Article 23, an incident is significant if it "has caused or is capable of causing severe operational disruption of the services or financial loss" to your organisation. Then an early warning to the CSIRT is due within 24 hours of becoming aware of it. For most companies a mail and collaboration outage is an internal disruption, not a severe one, but you have to decide and document that, not assume it. Our incident clock works out the NIS2, DORA and GDPR deadlines from the time you became aware.
Evidence for later: save the Service health timeline, your internal communications and the business impact (which processes stopped and for how long). Auditors will ask about third-party ICT risk and business continuity, and a real event with a written record is better evidence than a tabletop exercise.
After it's over: three questions to answer
Which critical processes stopped because they depend on Exchange or Teams? Think approvals, customer notifications, alerting and the incident bridge itself.
Does your break-glass and incident communication plan work when Microsoft 365 is the thing that's down?
Did anyone loosen security controls during the outage to work around it, and has that been rolled back?
If you want a second pair of eyes on how your tenant and processes came through, our Microsoft 365 security audit covers resilience, Conditional Access and the controls people tend to bypass under pressure. The free M365 identity check is a quick start.
Questions
Is Microsoft 365 down right now?
As of about 10:00 UTC on 13 November 2026, Microsoft was rolling out a patch for incident MO1550821 and reported early stabilisation, but capacity was not back to normal and the incident was not resolved. Check Service health in the Microsoft 365 admin center, or status.cloud.microsoft, for the current state.
Was the Microsoft 365 outage a cyberattack?
Microsoft says there is no indication of malicious activity. Its updates point to servers failing health checks and a connection-handling process becoming overwhelmed, with a recent network configuration change being reverted.
Do I need to report the Microsoft 365 outage under NIS2?
Only if it caused, or could cause, severe operational disruption of your services or financial loss to your organisation. Assess it against that test, document the decision, and if it is significant, send the early warning within 24 hours of becoming aware.
Did the outage expose gaps in your continuity plan?
We review how your company runs when Microsoft 365 is unavailable: out-of-band communication, break-glass access, alerting outside Microsoft, and the incident records NIS2 and DORA expect.
This is a developing story, last checked 13 Nov 2026 around 11:30 UTC. Service health in your admin center is the authoritative source for your tenant.