Exchange Online health-check failures knocked out Outlook, Teams and Copilot for over a day

What happened

Microsoft 365 suffered a prolonged, worldwide outage beginning at 18:26 UTC on November 12, 2026. According to a summary of Microsoft's status updates published on dev.to by Control Plane, the incident — tracked as MO1550821 — started with Exchange Online and Outlook failures in the Americas before spreading to other regions and to services that sit on top of Exchange, including Teams, Microsoft 365 Copilot, SharePoint Online, Intune and Defender for Office 365.

The Register reported that, beyond email, Teams, Cloud PCs and Copilot, users lost full access to roughly 15 other hosted services, and that Microsoft classified the event as a service degradation rather than a full outage. Microsoft 365 Education was among the affected offerings.

Recovery was slow. A separate, earlier Teams incident had already been opened and resolved that same afternoon, according to the timeline on dev.to. More than 20 hours after MO1550821 began, Microsoft was still reporting intermittent problems: improvement across North America and much of Europe came during November 13, followed by early recovery in Asia Pacific, and a later update noting that email queues had been significantly reduced.

A cascading failure, by Microsoft's own description

Microsoft's updates, as reported by BleepingComputer and The Register, point to a capacity collapse rather than a spike in demand. Servers in Exchange Online began failing their automated health checks and dropped out of service, pushing their load onto the remaining fleet until those machines were overwhelmed too. Microsoft stated the elevated load was not driven by increased traffic, and said it had no indication of malicious activity.

Later updates added that the failures may originate in a component responsible for processing server health, and that a core process on affected servers was being overwhelmed to the point that the servers stopped responding.

This matches a well-understood failure mode in distributed systems: a cascading failure. Health checks exist to take broken servers out of rotation, but when too many fail at once, the survivors absorb the extra load, then fail their own checks, and the cycle repeats. Microsoft's recovery difficulties reflected exactly that dynamic. Servers that passed a validated alternative health check method became unresponsive again once real traffic returned, and attempts to scale up virtual machines were hindered by machines stuck in a bad state that prevented changes from syncing. At one point Microsoft acknowledged that its actions had not produced the relief it expected.

Mitigations included pausing deployments, redistributing traffic, restarting servers, replacing the health check method, and extending the email delivery timeout to 48 hours so queued mail would not bounce. Microsoft was also assessing whether reverting a small number of recent configuration updates could speed recovery. Executive Charles Lamanna said teams were reviewing what happened and how to prevent similar issues.

What is still unknown

The trigger remains a mystery. Microsoft has not said what made the servers start failing their health checks, whether a deployment or configuration change was involved, or how a repeat will be prevented; no post-incident review has been published yet.

Azure appears to have been spared. Its status page showed no active events, and Microsoft has not confirmed any impact on customer-hosted Azure workloads, as dev.to notes. The virtual machines referenced in the updates seem to belong to Microsoft's own Exchange Online infrastructure, though the company has not said so explicitly. That distinguishes this event from the October 29, 2025 Azure Front Door incident, which Microsoft attributed to incompatible configuration metadata and which affected Azure services such as App Service and SQL Database as well as Microsoft 365.

Reaction and the concentration question

The Register framed the outage as a lesson in single-vendor dependence. Nextcloud co-founder Jos Poortvliet said mistakes happen at every company but argued the incident shows how reliant organizations have become on one ecosystem, noting that firms tied to a single vendor cannot quickly switch providers or keep a second setup as backup. Civo CEO Mark Boost said the real concern is not that Microsoft suffered an outage, but that critical infrastructure has become concentrated among so few companies, creating enormous single points of failure. Chi Onwurah, chair of the UK Commons Science and Technology Committee, said the event highlighted the lack of resilience in the UK's digital infrastructure.

A post on jsweeting.me described businesses redirecting customers to social media, disruption at schools, universities and courts, and office workers treating the day as an unplanned holiday. Those accounts are anecdotal, but their breadth is consistent with the service list Microsoft itself disclosed.

Why it matters

Customers cannot fail Exchange Online over to another provider in the middle of an incident. What they can control is how much of the business stops when email and collaboration tools degrade — a question that is likely to resurface at contract renewal time, as The Register notes.

For platform engineers, the incident is a reminder that the health check system itself can be a single point of failure: if it can drain an entire fleet at once, a fault in it takes down everything it monitors. Standard defenses include limits on how much capacity health checks can remove at once, spare capacity in each failure domain, load shedding, and staged deployments with automatic pause.

Until Microsoft publishes its post-incident review, the underlying trigger — and whether a configuration change started the cascade — remains open.