DAILY ANALYSIS
Microsoft 365 outage: How Exchange Online lost capacity and what could have helped
The November 12 Exchange Online incident affected mailbox access and other Microsoft 365 workflows. Here is how the failure spread and what providers and customers can do to reduce the impact.
What happened
Microsoft recorded the start of Exchange Online incident EX1550543 at 11:17 a.m. Eastern (16:17 UTC) on November 12. Users could lose access to mailboxes through several connection methods. Microsoft tracked broader Microsoft 365 effects under MO1550821. The PennO365 mirror preserves Microsoft’s incident updates and distinguishes mailbox and calendar access from related problems such as intermittent Power Platform failures.
How the disruption spread
Microsoft’s updates described servers becoming unavailable and recovery work to stabilize the affected environment before restoring capacity. When a pool loses servers, the remaining servers must handle more traffic. Repeated connection attempts can increase the pressure. Think of it as a feedback loop: less usable capacity leads to longer waits, longer waits prompt retries, and retries consume more capacity. This explains a plausible amplification mechanism. The public updates do not establish an exact load increase or the final initiating cause.
Why the business impact varied
A failed mailbox connection can interrupt approvals, customer replies and meeting coordination. A workflow that depends on the same service can also stall even when its own interface opens. Map impacts by workflow and tenant rather than assuming every Microsoft 365 product was completely offline for the same period. Keep a record of what failed, when it recovered, and what backlog still needs reconciliation.
What Microsoft could have done better
Limit how much capacity automated health checks can remove at once. Tie removal decisions to spare capacity and distinguish a genuinely failed instance from an instance slowed by a shared dependency. Protect recovery capacity with request limits and separate failure domains. Cap retries, use exponential backoff with jitter to spread them out, and shed optional traffic while the system stabilizes. Reintroduce traffic in small steps and use end-to-end mailbox access, error rate and latency to decide whether to proceed or roll back. Exercise this scenario under load before relying on the safeguards. These are engineering recommendations, not claims about which safeguards Microsoft had in place.
What customers can do before the next outage
Give incident leads a contact list and a way to reach staff that can function when both Outlook and Teams are unavailable. Keep approved offline copies of critical runbooks and define which time-sensitive workflows may move to a backup channel. Protect customer data and payment instructions with existing verification rules. During an outage, avoid blanket job restarts and uncontrolled retries. After recovery, test inbound and outbound mail with a known external mailbox and reconcile queued or duplicate actions before closing the incident.
Recovery status
Sources checked November 13, 2026. Microsoft’s incident updates describe staged recovery and report conditions that can differ by region, tenant and feature. Use Microsoft Service Health for your tenant’s current status and verify your own critical workflows. This article does not assign one recovery time to every customer.