The Microsoft 365 outage that began on Thursday, 12 November, left businesses trying to work without their usual email and collaboration tools. Outlook connections failed, messages were delayed and features in Teams and Copilot stopped behaving normally. By Friday, Microsoft was reporting progress, but a successful login did not necessarily mean a mailbox was receiving new mail.
At 15:52 UTC on 13 November, Microsoft was still reporting residual problems under incident MO1550821. The company's service messages reproduced by the University of Pennsylvania identify Exchange Online and services that depend on it as a major part of the remaining disruption. The incident record gives the start time as 18:26 UTC on 12 November.
The investigation was still open at that point. Microsoft said it had found no evidence of malicious activity and would issue a full incident report after mitigation. That is the company's assessment at the time, not a completed root-cause analysis.
What stopped working?
Microsoft's update describes failures across several ways of connecting to an Exchange Online mailbox: Outlook on the web, desktop clients using MAPI, mobile synchronization through Exchange ActiveSync and REST-based connections. Email delivery could be delayed independently of a user's ability to open the mailbox.
Some Microsoft 365 administration pages could fail to load. Copilot could struggle to retrieve work information such as messages and calendars. Teams experienced problems with parts of its chat and channel functionality, while certain SharePoint sharing operations were affected. The later incident notice distinguished those problems from features that did not depend on Exchange Online: direct access to files in SharePoint remained functional.
That distinction explains why two colleagues could report different experiences. One might still open a document stored in SharePoint while another cannot receive an email containing a link to it. A third might be able to enter Teams but find that a particular operation fails. A screenshot of one working application tells us little about the health of the whole suite.
The Associated Press report on 13 November documented interruptions to business communications and public services, including court proceedings and police reporting in Britain. Reuters' coverage also reported international disruption. User reports demonstrate the breadth of symptoms, but do not provide an exact count of all affected accounts.
How a loss of server capacity can become a wider outage
Microsoft's Thursday incident updates described a developing investigation. Engineers initially observed high load and tried moving traffic, restarting servers and restoring capacity. Later messages said that many servers were unexpectedly unavailable, concentrating demand on the infrastructure still working. The company also investigated failing health checks and a core process that was becoming overwhelmed.
Consider a hypothetical service with 100 identical workers that normally operate at 60% utilization. If 40 workers become unavailable and demand does not fall, the other 60 would need to operate at 100% utilization just to handle the original workload. There is no margin for bursts, retries or background work. Requests can time out, prompting clients to try again and adding further pressure.
This is an illustration, not a measurement of Microsoft's fleet. It shows why redirecting requests is not always enough. Traffic can only be moved successfully if the destination has sufficient healthy capacity and does not share the component that failed.
Microsoft reported isolating some infrastructure, restarting components and admitting traffic gradually to check that services remained stable. It also investigated a recent change associated with health-check processing. None of these interim messages establishes the final cause. In particular, there is no verified basis here to connect the outage to the separate Outlook security vulnerabilities disclosed earlier in the week.
Recovery takes longer than getting servers back online
A service can start accepting connections before it has finished dealing with work accumulated during an interruption. Email is a particularly clear example.
When a receiving system temporarily cannot accept a message, sending mail servers may queue the message and retry delivery. Exchange may also have internal work waiting to be processed. As the service returns, normal incoming traffic competes with those queues. Delivery delays can outlast the initial connection problem.
A user who receives fresh mail at noon may therefore still be missing a message sent earlier in the morning. Delayed delivery is not proof of permanent message loss either. The answer for a particular message depends on the sending system, the recipient's service and whether delivery has ultimately succeeded.
Connection success, message-delivery latency, queue depth and error rates describe different parts of recovery. Microsoft was reporting improvements in email delivery on Friday, but its incident record continued to list delayed mail as a possible symptom.
Is Microsoft 365 still down?
The status recorded above applies to the afternoon of 13 November 2026, not every later visit to this article. For current information, the Microsoft service status site is the appropriate starting point. Organizations with access to the Microsoft 365 admin center can obtain tenant-specific information under Service health, including incident identifiers and vendor updates.
An unrelated local connection or authentication problem may persist after the global incident ends. An outage headline cannot diagnose an individual mailbox, and the absence of a new headline does not establish that every tenant has recovered.
The cost of putting every communication channel in one suite
A company may rely on Outlook for email, Teams for incident coordination and a Microsoft-hosted identity service for access to internal tools. If its emergency contact list is stored in the same environment and its customer status page requires the same identity system to publish updates, a provider disruption can complicate the response to that very disruption.
For a hosting business, the risks extend to support tickets, abuse notifications, upstream coordination and customer communications. A working server fleet is not much consolation if customers cannot report problems or reach support. An alternative communication channel has value only if the people expected to use it can still authenticate, retrieve the necessary information and reach one another during the original failure.
Our analysis of cloud regions and correlated failures examines the same engineering issue at the infrastructure level. The lesson from this outage is broader than geography: redundancy needs independent failure boundaries. A second interface backed by the same service is not necessarily a second route to recovery.