Microsoft 365's November 12 Outage: Failing Health Checks and a Network Change

Microsoft 365 incident EX1550543 started on November 12, 2026, at about 16:17 UTC. Microsoft later said Exchange Online servers were failing automated health checks and becoming unavailable, leaving the remainder overloaded. It has since tied the outage to a network capacity upgrade issue exposed by a recent network change. The full post-incident report is still pending.

What happened, in UTC

Microsoft posted 37 updates through 17:57 UTC on November 13. The ones that matter for understanding the failure:

The user-facing blast radius went well beyond email. Euronews reported Outlook, Teams, Copilot, SharePoint Online and Defender XDR affected, close to 140,000 Downdetector reports for Outlook alone, and problems reported in 74 countries and territories. Microsoft said repeatedly that it saw no sign of malicious activity.

What Microsoft says caused it, so far

Here is the sequence as we reconstruct it from Microsoft's updates. A network change went out. Affected servers started failing automated health checks and became unavailable; at 19:57 Microsoft said it had taken steps to stop more servers being removed from service. Their traffic moved to the servers still standing, and at 19:18 UTC Microsoft stressed that the load "isn't driven by an overall increase in traffic". At 01:06 Microsoft said a process on the affected servers that establishes secure connections was becoming overwhelmed. Restarted servers could go unresponsive again once they took traffic.

Two things in that record deserve care. First, the explanation moved. At 19:57 on November 12 Microsoft said it had found no recent change lining up with the start of impact; five hours later it was reverting a network configuration change that did. Second, the 17:57 UTC update on November 13 is the closest thing to a root cause: an earlier network capacity upgrade issue that surfaced after a recent network change. Microsoft has not said whether the health-check failures were a symptom of that network problem or a separate fault that amplified it.

Our reading, which is not Microsoft's claim: this has the shape of a health-check death spiral. Ejecting unhealthy servers is correct when a few are sick. When the check itself, or the network under it, misfires across a large share of the fleet, ejection concentrates load on whatever remains and turns a partial problem into a total one. Restarts don't help while retried and redirected connections are queued behind every returning server, which matches the 23:59 update. The pause on deployments at 19:06 and the move to an alternative health check at 20:56 are what you would do if you suspected the checks themselves.

Am I affected?

If your users are back in Outlook, the remaining risk is mail that was delayed, not lost. Microsoft extended the email timeout window to 48 hours, so messages sent during the outage should keep retrying rather than bouncing. Two checks tell you where you stand: the incident status from your own tenant, and any mail still pending.

# Incident status for your tenant (needs ServiceHealth.Read.All)
Connect-MgGraph -Scopes ServiceHealth.Read.All
Get-MgServiceAnnouncementIssue -ServiceHealthIssueId EX1550543 |
  Select-Object Id, Status, IsResolved, StartDateTime, EndDateTime, LastModifiedDateTime

# Messages still pending or failed since the outage began (Exchange Online PowerShell)
Connect-ExchangeOnline
Get-MessageTraceV2 -StartDate "11/12/2026 16:00" -EndDate (Get-Date) -Status Pending,Failed -ResultSize 5000 |
  Group-Object Status | Select-Object Name, Count

Message trace timestamps come back in UTC, and one query covers at most 10 days and 5,000 results, so narrow the window or filter by -SenderAddress for a large tenant. If you run Exchange hybrid, check the on-premises side too: Get-Queue -Filter "MessageCount -gt 100" on your Exchange Server shows outbound queues to Exchange Online that backed up and should now be draining. A queue that stays large after Microsoft reports recovery is your problem to chase, not theirs.

The lesson for your own health checks

Every load balancer and service mesh you run makes the same decision Exchange Online made: when a backend fails its check, stop sending it traffic. The guard that matters is what happens when a large share of backends fail at once. Envoy's answer is the panic threshold: if fewer than 50% of hosts in a cluster are healthy (the default), it ignores health status and spreads traffic across every host. A bad check then degrades service instead of collapsing it.

clusters:
- name: mailbox_backend
  common_lb_config:
    healthy_panic_threshold:
      value: 50.0          # below 50% healthy, stop trusting the checks
  outlier_detection:
    consecutive_5xx: 5
    max_ejection_percent: 10   # the default; never raise it to 100

Three rules come out of this outage. Cap how much of a fleet any automated check can remove, with a panic threshold or max_ejection_percent. Treat a sudden mass failure of checks as a likely fault in the check or the network, not in every server at once. And bring capacity back slowly, with slow start and jittered client retries, so restored servers don't take the full backlog in their first second. We covered the single-server version of this trap in readiness probes that lie during rolling updates, and the DNS-level version in Route 53 health checks for multi-region failover.

Where this breaks

The panic threshold is not free. In panic mode, traffic does reach servers that really are broken, so some requests fail. That is the trade: partial errors instead of a full outage. It also doesn't help when the failure is capacity rather than the check, which seems to have been part of this incident once the secure-connection process was overwhelmed. There, the levers are traffic limits and blocking, which Microsoft applied overnight.

What is still unknown as of November 13, 2026: what the network capacity upgrade issue was, whether the component Microsoft suspected at 19:57 was part of the same fault, and why the explanation shifted overnight. Microsoft has promised a post-incident report with the root cause and defense-in-depth actions. We will update this post when it lands.

Questions people ask

Was the Microsoft 365 outage a cyberattack?

No, according to Microsoft. From early November 13 its Service Health updates said there was no sign of malicious activity, and the 17:57 UTC update said it was a technical issue unrelated to cyber activity or AI agents. It attributed the outage to a network capacity upgrade issue exposed by a recent network change, with the full root cause due in a post-incident report.

Will I lose emails sent during the outage?

Probably not. Microsoft extended the email timeout window to 48 hours so delayed messages keep retrying instead of bouncing back to senders. Some mail arrived hours late. To confirm nothing is stuck, run Get-MessageTraceV2 with -Status Pending,Failed for the outage window, and check on-premises queues with Get-Queue if you run Exchange hybrid.

When will Microsoft publish the root cause?

In its 15:53 UTC update on November 13, Microsoft committed to a full post-incident report with root cause and defense-in-depth actions after mitigation is complete. The 17:57 update repeated that a full report will follow once its review is done. Microsoft has not given a date as of November 13, 2026.

The call we'd make

Don't spend the week moving off Microsoft 365 over one bad day. Spend an hour on two things: confirm with message trace that no mail is still stuck in your tenant, then look at every health check you own and ask what happens when half your fleet fails it at once. If the answer is "everything gets ejected", add a panic threshold or an ejection cap before your own version of EX1550543 finds you. The caveat: Microsoft's root cause is not final yet, and the report may change the story.

Sources

• Cloud Admin Hub: EX1550543 Service Health update timeline
• Microsoft Graph: Get serviceHealthIssue
• Microsoft Learn: Get-MessageTraceV2
• Envoy: Panic threshold