Microsoft 365 Outage (Nov 2026): What We Know About the Root Cause and What IT Admins Should Learn

Microsoft has not yet published the root cause of the Microsoft 365 outage that began on 12 November 2026 (EX1550543 for Exchange Online, MO1550821 for multiple Microsoft 365 services). What it has said so far points at servers that became unavailable, an overwhelmed secure-connection process and a recent network configuration change that correlates with the start of impact; the full explanation is promised in a Post-Incident Report (PIR) after mitigation. This guide collects Microsoft's own statements with their timestamps and turns the outage into practical lessons for enterprise IT teams.

Status as of 20:26 IST, 13 November 2026 (14:56 UTC; 9:56 a.m. ET): Microsoft's public status page still lists "Service degradation". Microsoft says it is "observing sustained improvements in service availability" but "some users may still experience intermittent connectivity issues or delayed email delivery", and that it will share the PIR "after mitigation is complete". No PIR has been published. For live status, workarounds and SLA terms, see the main guide: Microsoft 365 outage: Outlook down, status and what to do.

Who this guide is for

IT administrators, IT managers and small-business owners who run on Microsoft 365 and want to be better prepared next time: faster detection, clearer communication, and a plan for working while Outlook and Teams calendars are unavailable. EpiFive is not affiliated with Microsoft. Every statement about the cause below is quoted from Microsoft's Service health posts; nothing is guessed.

What happened

Microsoft dates EX1550543 from 16:17 UTC on 12 November 2026 (11:17 a.m. ET; 9:47 p.m. IST). Users in every region could not reliably reach Exchange Online mailboxes through Outlook on the web, Outlook desktop, mobile mail apps or REST, and features in Teams, Copilot, Purview, Defender, Intune, Planner and other services that depend on Exchange Online failed with it. The broader incident, MO1550821, starts at 18:26 UTC. The main guide has the full update-by-update timeline; the table below keeps only the updates that matter for the cause and the recovery.

Times are from the Service health posts for EX1550543 unless marked MO1550821, as published in the University of Pennsylvania's public mirror of the feed. ET is UTC-5 and IST is UTC+5:30.

Root cause: what Microsoft has said so far

Root cause: pending Microsoft's Post-Incident Report. The statements below are Microsoft's own words, in order. They describe symptoms, actions and correlations; Microsoft has not said which of them, if any, is the root cause.

1. 19:06 UTC, 12 November (EX1550543): "As a precaution, we've paused all deployments and configuration changes while we review recent changes for any correlation to this event."
2. 19:18 UTC, 12 November (EX1550543): "We've determined that the elevated load isn't driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure."
3. 19:43 UTC, 12 November (EX1550543): "We've identified that affected servers are failing automated health checks, which is causing them to become unavailable, and this may be related to a recent change to a component involved in processing those checks."
4. 19:57 UTC, 12 November (EX1550543): "While we haven't identified any recent changes that correlate with the start of impact, our investigation indicates the failed health checks may originate from a specific component on the affected servers that's responsible for processing them."
5. 01:06 UTC, 13 November (EX1550543): "Our investigation has found that a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests." In the same update: "In parallel, we've begun reverting a recent network configuration change that correlates with the start of impact and are monitoring to determine whether this contributes to recovery."
6. 03:34 UTC, 13 November (EX1550543): "we can confirm that there is no indication this is the result of malicious activity."
7. 05:43 UTC, 13 November (EX1550543): "As of now, we are not aware of any malicious activity that is causing this incident." And: "Once mitigated, we will provide full details of the root cause, defense-in-depth repair items, and more within a Post-Incident Report."
8. 07:25 UTC, 13 November (EX1550543): "We're seeing positive results for server stability after applying an upstream authentication/routing configuration component patch to a portion of our infrastructure."
9. 14:01 UTC, 13 November (EX1550543 and MO1550821): "At this time, we have no evidence of malicious activity associated with this incident. We will continue to treat this with urgency until full mitigation, and we will share a full Post-Incident Report with root cause and defense-in-depth actions after mitigation is complete."

Two things are worth noticing. First, Microsoft's view of recent changes moved: at 19:57 UTC it had not found a change that correlated with the start, and by 01:06 UTC it was reverting one that did. Second, "correlates with" is not "caused". The incident record still shows "Root Cause: N/A". This article will be updated with Microsoft's stated cause when the PIR is published.

How to check service status automatically

If the first sign of an outage is a user saying Outlook will not connect, monitoring is too slow. Build three independent signals, and make sure none of them depends on the service that is failing.

Service health notifications, sent somewhere that still works

In the Microsoft 365 admin center go to Health > Service health > Customize > Email, select Send me email notifications about service health, and choose incidents and advisories for the services you care about (Exchange Online, Microsoft Teams, SharePoint Online, Microsoft Entra). You can add up to two email addresses. The lesson from this incident: an alert about Exchange Online that is delivered only to an Exchange Online mailbox may arrive late or not at all. Make one of the two addresses a mailbox that is not hosted in your tenant, such as a monitored mailbox with another provider that forwards to SMS or chat.

Also install the Microsoft 365 Admin mobile app on at least two admins' phones and turn on its push notifications, so the alert does not depend on anyone's Outlook.

Poll the Microsoft Graph service communications API

The Service Communications API returns the same incidents and advisories as Service health. It needs the ServiceHealth.Read.All permission, delegated or application, so you can run it unattended with an app registration and a certificate.

GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/healthOverviews
GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/issues
GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/issues/EX1550543/incidentReport

In Microsoft Graph PowerShell, a minimal check that lists unresolved incidents for the services you track looks like this:

Connect-MgGraph -Scopes "ServiceHealth.Read.All"
$watch = 'Exchange Online', 'Microsoft Teams', 'SharePoint Online', 'Microsoft 365 suite'
Get-MgServiceAnnouncementIssue -All |
  Where-Object { -not $_.IsResolved -and $_.Classification -eq 'incident' -and $_.Service -in $watch } |
  Select-Object Id, Service, Status, Title, StartDateTime, LastModifiedDateTime

Run it every 5 to 10 minutes from a scheduler outside your Microsoft 365 tenant, and send new incident IDs to the on-call channel by SMS or a chat tool. Treat a failed API call as an alert too: during this incident Microsoft listed Graph requests that touch Exchange Online data as affected, so a monitor that only alerts on a successful "incident found" response can stay silent when it matters. The incidentReport call returns the PIR once Microsoft publishes it, which makes it easy to collect for your own review.

Watch the public status page and the official account

status.cloud.microsoft is Microsoft's public status page for when you cannot sign in to the admin center, and @MSFT365Status on X posts short versions of major updates. Microsoft does not document an API for the public page, so treat any automated check of it as best effort; a simple uptime or change monitor that opens the page and notifies you when it changes is enough. User-report sites such as Downdetector can warn you early, but they count reports, not confirmed impact.

An escalation runbook

Write down, before the next outage, who does what:

• Trigger: a Service health incident for a core service, or more than a handful of user reports in 15 minutes.
• First 15 minutes: confirm in Service health or on status.cloud.microsoft that it is Microsoft's incident, not your network or sign-in; note the incident IDs.
• First 30 minutes: send the first staff message (template below) through an out-of-band channel; name an incident owner and a next-update time.
• Ongoing: follow the incident IDs, update staff at the times you promised, and log business impact with UTC times for an SLA claim.
• After recovery: run message traces for critical senders, check Outboxes, collect the PIR, and hold a short internal review.

What admins should do: a communication plan that works without Microsoft 365

The usual internal channels, email and Teams, are the ones most likely to be degraded in a Microsoft 365 outage. Teams chat and meetings mostly kept working this time, but calendars and invites did not, and nobody can count on that pattern next time.

Pick an out-of-band channel now. Options include an SMS broadcast service, a WhatsApp or Signal group for staff (with the same data rules as any other channel), a phone tree, or a simple public or internal status page hosted outside Microsoft 365. A self-hosted page such as Statuszen works if it runs on infrastructure that does not sign in through your tenant. Keep the subscriber list current and test it twice a year.

Staff template (send in the first 30 minutes, then at each promised time):

Microsoft 365 incident - Outlook and some Teams features affected
 
Microsoft is working on a service incident (ID: <incident ID>). Outlook may
not connect and Teams calendars or invites may fail. This is a Microsoft-side
problem, not a fault on your device.
 
Please:
- Do not reset your password, reinstall Office or delete your Outlook profile.
- Keep working from mail and files already on your device.
- Ignore any email asking you to sign in "to restore your mailbox".
- For urgent matters, call or message the person directly.
 
Next update: <time and time zone>. IT on call: <phone number>.

Customer template (for your website, social channels or an auto-reply that does not depend on Microsoft 365):

Service notice - email delays
 
A global Microsoft 365 incident is delaying some of our email. Messages sent
to us are normally queued and delivered when the service recovers, so there is
no need to resend yet. For anything urgent, please call <phone number> or use
<chat or form link>. We will post an update at <time and time zone>.

Keep both templates, the subscriber lists and the on-call numbers somewhere that does not sit in OneDrive, SharePoint or a mailbox: a printed copy, a password manager with offline access, or a document in another provider's storage.

What users can do during the next outage: business continuity

Most of the continuity that helped in this incident was set up before it began.

• Offline mail. Classic Outlook for Windows keeps a local copy of the mailbox in Cached Exchange Mode, so mail already downloaded stays readable. New Outlook for Windows has its own offline mode: Microsoft says it is on by default and saves email, calendar events and people to the device, configurable under Settings > General > Offline, with 30 days of email saved by default (7, 30, 90 or 180 days). Check which client your users have and what it keeps offline.
• Offline files. OneDrive Files On-Demand only opens online-only files when the device is connected. For files people need in an emergency (contracts, price lists, rotas), right-click the folder and select Always keep on this device; Microsoft says those files "are always there for you even when you're offline". Known Folder Move with Intune can make sure Desktop and Documents are in OneDrive in the first place (see OneDrive Known Folder Move with Intune).
• An emergency meeting bridge. Keep one meeting option that does not depend on Microsoft 365, such as a dial-in conference number from another provider, and share it in advance. Also keep standing Teams meeting links for key meetings in a document outside the mailbox, because calendar invites failed in this incident while joining meetings mostly worked.
• Contacts and phone numbers outside Microsoft 365. Key staff, customers, suppliers, your Microsoft partner and your internet provider, kept in a printed list or an offline copy, not only in Outlook contacts.
• Break-glass admin accounts, used for the right problem. Microsoft recommends two or more cloud-only emergency access accounts on the *.onmicrosoft.com domain, protected with a phishing-resistant method such as a passkey (FIDO2), excluded from Conditional Access policies that block sign-in, monitored for every sign-in and validated at least every 90 days (see break-glass accounts in Entra ID). They solve lockouts from your own tenant, such as a federation or MFA failure. In a Microsoft-side outage like this one the issue is not your tenant: disabling Conditional Access, resetting passwords or changing mail flow will not bring the service back and can create a second incident.

Change management lessons from "a configuration change correlated with impact"

Microsoft has not confirmed that a configuration change caused this outage. Its 01:06 UTC update says only that it began reverting one that "correlates with the start of impact". But the shape of the incident, with servers failing health checks and load cascading onto the rest, is a reminder that your own changes deserve the same discipline.

• Stage every change. Apply Conditional Access policies in report-only mode first (see Conditional Access report-only mode), run mail flow rules in Test without Policy Tips before Enforce (see Exchange Online mail flow rules), and use device update rings and pilot groups in Intune.
• Use an early release group. Put IT staff and a few volunteers on an earlier release channel so they meet Microsoft's feature changes before everyone else. Targeted release is being replaced, so plan the move described in Targeted release retirement: Standard, Deferred or Frontier.
• Write the rollback before the change. For every change: the exact command or setting to undo it, who can approve the rollback, and what signal triggers it.
• Freeze during incidents. Microsoft paused "all deployments and configuration changes" within three hours of the start. Do the same in your tenant while a major incident is open, so you do not mix your change with Microsoft's.
• Keep a change log with UTC times. When a vendor says a change "correlates with the start of impact", the first question in your own review will be what changed in your environment at the same time.

SLA credits

The SLA terms, credit tiers and claim deadline are in the main guide's SLA credits section; they are not repeated here. What to do now is document impact while it is fresh: which users and sites were affected, from and to what time in UTC, which connection methods failed, the exact error messages, the incident IDs (EX1550543, MO1550821) and screenshots of Service health. For a November incident on a monthly subscription, the claim must reach Microsoft by 31 December 2026. If you buy through a Microsoft partner (CSP), ask the partner how they file the claim.

Post-incident review

As of 20:26 IST, 13 November 2026, Microsoft has not published a post-incident review for EX1550543 or MO1550821; both are still open. Microsoft's service description says that for incidents with "broad and noticeable impact across a large number of organizations", a preliminary PIR is delivered through Service health "within 48 hours of incident resolution, followed by a final PIR within five business days". When it is out, the incident status changes to Post-incident report published, and you can download it from the incident in Service health or with the incidentReport Graph call above.

How to read it. A Microsoft PIR covers user impact, start and end times, a detailed timeline and the root cause analysis, plus the repair items Microsoft calls defense-in-depth. Read it in this order:

1. Start and end times. Compare them with your own impact log; they drive any SLA claim.
2. Root cause. Note whether it was a change, a capacity issue, a dependency or a combination, and whether it confirms or contradicts the statements above.
3. Detection. How long between the start time and Microsoft's first post, and between that post and your first internal alert?
4. Repair items. What Microsoft will change, and by when.

What to review in your own environment afterward. Did your alerts fire, and through which channel? How long did staff wait for the first message? Which continuity items worked (offline mail, offline files, the meeting bridge) and which did not? Were any of your own changes made during the incident? Update the runbook, templates and checklist below with the answers.

Checklist

• Service health email notifications on, with one address outside your Microsoft 365 tenant.
• Microsoft 365 Admin app with push notifications on two admins' phones.
• Graph service health monitor (ServiceHealth.Read.All) running outside the tenant, alerting by SMS or chat, and alerting on API failure.
• status.cloud.microsoft and @MSFT365Status bookmarked in the runbook.
• Escalation runbook with an incident owner, first-message deadline and update rhythm.
• Out-of-band staff channel (SMS, WhatsApp or a status page) tested this quarter.
• Staff and customer message templates stored outside Microsoft 365.
• Offline mail checked for both classic and new Outlook users.
• Critical folders set to Always keep on this device.
• Emergency meeting bridge and contact list kept outside Microsoft 365.
• Two break-glass accounts, excluded from blocking Conditional Access, sign-in tested within the last 90 days.
• Change freeze rule for major incidents; rollback plan required for every change.
• Impact log template (UTC times, users, errors, incident IDs) ready for SLA claims.
• Calendar reminder to download the PIR for EX1550543 and MO1550821 and hold an internal review.

What we checked

• Opened Microsoft's public status page data (status.cloud.microsoft) at 20:30 IST on 13 November 2026: the Microsoft 365 post was last updated 14:56 UTC (20:26 IST), status "Service degradation", with the "sustained improvements" wording and the PIR promise quoted above.
• Read the full update history of EX1550543 and MO1550821 in the University of Pennsylvania's public mirror of Microsoft's Service health feed, generated 09:50 a.m. ET (14:50 UTC) on 13 November; every quote and time in the root-cause section comes from it. Both incidents show "Root Cause: N/A" and "End Time: Not ended yet".
• Converted each UTC time to ET (UTC-5) and IST (UTC+5:30) and checked them against the timeline in the main guide.
• Checked reputable reporting from 13 November for any published root cause or PIR; none was reported.
• Read Microsoft Learn for the Graph serviceAnnouncement list-issues API (permission ServiceHealth.Read.All, delegated or application), emergency access accounts (two or more cloud-only accounts, FIDO2 or certificate-based authentication, validate at least every 90 days), and the post-incident review timing; and Microsoft Support for new Outlook offline settings and OneDrive Always keep on this device.
• Not verified: the root cause, which Microsoft has not published, and how the monitoring script behaves during a live outage. The PowerShell check uses documented cmdlets and properties but was not run against an affected tenant.

Last tested: 2026-11-13

Sources

• Microsoft 365 Service health, EX1550543 and MO1550821, as mirrored by the University of Pennsylvania: https://mailservices.isc.upenn.edu/computing/email/penno365/alerts/ms-incidents.html
• Microsoft 365 status page: https://status.cloud.microsoft
• Microsoft 365 Status on X: https://x.com/MSFT365Status
• Microsoft Learn, How to check Microsoft 365 service health: https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health
• Microsoft Learn, Service health and continuity (post-incident reviews): https://learn.microsoft.com/en-us/office365/servicedescriptions/office-365-platform-service-description/service-health-and-continuity
• Microsoft Learn, Service communications API in Microsoft Graph: https://learn.microsoft.com/en-us/graph/api/resources/service-communications-api-overview
• Microsoft Learn, List issues (serviceAnnouncement): https://learn.microsoft.com/en-us/graph/api/serviceannouncement-list-issues
• Microsoft Learn, Get incident report: https://learn.microsoft.com/en-us/graph/api/servicehealthissue-incidentreport
• Microsoft Learn, Manage emergency access admin accounts: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
• Microsoft Support, Offline in the new Outlook for Windows: https://support.microsoft.com/en-us/office/work-offline-in-outlook-for-windows-f3a1251c-6dd5-4208-aef9-7c8c9522d633
• Microsoft Support, Turn on Cached Exchange Mode: https://support.microsoft.com/en-us/office/turn-on-cached-exchange-mode-7885af08-9a60-4ec3-850a-e221c1ed0c1c
• Microsoft Support, Save disk space with OneDrive Files On-Demand for Windows: https://support.microsoft.com/en-us/office/save-disk-space-with-onedrive-files-on-demand-for-windows-0e6860d3-d9f3-4971-b321-7092438fb38e
• Microsoft, Service Level Agreement for Microsoft Online Services: https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services
• Euronews, Microsoft outage explained: https://www.euronews.com/2026/11/13/microsoft-outage-explained-what-went-wrong-and-is-your-data-at-risk
• SecurityWeek, Microsoft 365 outage disrupts Outlook, Exchange Online and Teams: https://www.securityweek.com/microsoft-365-outage-disrupts-outlook-exchange-online-and-teams/
• BleepingComputer, Massive Microsoft 365 outage disrupts Outlook, Teams, Copilot worldwide: https://www.bleepingcomputer.com/news/microsoft/massive-microsoft-365-outage-disrupts-outlook-teams-copilot-worldwide/