On the afternoon of November 12, 2026 (US Eastern Time; early morning to morning of November 13 in Japan), a large-scale outage left users unable to connect to multiple Microsoft 365 services. Connection failures and feature limitations were reported in business applications including Outlook, Microsoft Teams, and Microsoft 365 Copilot, affecting corporate operations.
According to Microsoft, the outage did not take down every Microsoft 365 feature at once. A large number of servers in core infrastructure handling authentication and mailbox connectivity unexpectedly became unavailable, concentrating load on the servers that remained in operation and causing some functions to stop working properly. Features of Teams and SharePoint Online that depend on Exchange Online were also affected, revealing how dependencies between cloud services can widen the impact of a failure.
Microsoft 365 as a Whole Did Not Go Down
Immediately after the outage began, reports surged on the third-party outage tracker Downdetector not only for Outlook and Teams but also for Azure, OneDrive, and Microsoft Store. However, Downdetector's data is based on user-submitted reports and does not necessarily match the scope of the outage officially confirmed by Microsoft. The increase in reports for Azure, OneDrive, and Microsoft Store alone is not enough to conclude that the underlying platforms of those services had failed.
On its official service health page, Microsoft classified the status of Microsoft 365 Business and Enterprise as "Service degradation," noting that users might experience problems connecting to multiple services. In the Microsoft 365 admin center, the widespread outage was tracked as incident "MO1550821." The initial notice listed five affected services: Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot, and Microsoft Defender XDR.
| Service | Confirmed failures / feature limitations | Features that remained available | Scope / time confirmed |
|---|---|---|---|
| Exchange Online | Mailbox access failures via Outlook on the web, MAPI connections in desktop Outlook, Exchange ActiveSync, and REST connections; delayed mail delivery | Major connection paths in general may be affected; no path was identified as guaranteed to work | Initially the Americas, then expanded worldwide (afternoon of Nov. 12 US Eastern Time; from early Nov. 13 in Japan) |
| Microsoft Teams | Calendar display, creating meeting schedules, creating new chats in organizations using Information Barriers | Regular message sending and receiving, hosting and joining online meetings | Worldwide (part of MO1550821) |
| SharePoint Online | Some features that integrate with Exchange Online | Access to files stored directly in SharePoint Online | Worldwide (part of MO1550821) |
| Microsoft 365 Copilot / Defender XDR | Service connection failures, unresponsiveness | Details not disclosed | Worldwide (part of MO1550821) |
The impact varied by service. The most serious was Exchange Online, which Microsoft investigated under incident number "EX1550543." Users lost mailbox access through major connection methods, including Outlook on the web, MAPI connections used by desktop Outlook, Exchange ActiveSync for mobile devices, and REST-based API connections. Mail delivery delays were also confirmed, indicating broad impact on Exchange Online's core functions.
In Microsoft Teams, by contrast, major functions such as regular messaging and hosting or joining online meetings generally remained operational. The features that became unavailable were those that depend on Exchange Online, such as calendar display and creating meeting schedules. In environments with Information Barriers, which restrict communication within an organization, users also could not create new chats. SharePoint Online was likewise affected in its integration with Exchange Online, but access to files stored directly in SharePoint Online was maintained.
In other words, not all services in Microsoft 365 stopped at the same time; the failure appears to have spread to some features of other applications through their dependence on Exchange Online. However, the information confirmed so far is not enough to conclude that all symptoms had a single cause. For corporate IT administrators, the key is not to treat all of Microsoft 365 as unavailable, but to separate which functions are working normally from those that are affected, service by service.
The Morning Teams Outage and the Afternoon Widespread Outage Were Separate Incidents
Earlier on November 12, before the widespread outage, a separate Teams failure had occurred, so the successive incidents that day need to be distinguished. The US Eastern Times below are Eastern Standard Time (EST, UTC-5), which is 14 hours behind Japan Standard Time (JST, UTC+9).
The first was a Teams outage recorded in the Microsoft 365 admin center as "TM1550488." It lasted from 9:45 a.m. to 10:53 a.m. US Eastern Time on November 12 (11:45 p.m. on November 12 to 12:53 a.m. on November 13 in Japan) and mainly affected users in the Americas. Reported problems included delayed or failed message sending, errors when creating or updating conversation threads, and an inability to retrieve chat history.
Microsoft explained that this Teams outage was caused by resource contention in internal infrastructure, which drove resource utilization abnormally high and prevented messaging requests from being processed properly. The company announced that the issue was fully resolved as of 10:53 a.m. US Eastern Time on November 12 (12:53 a.m. on November 13 in Japan).
Afterward, at 11:17 a.m. US Eastern Time on November 12 (1:17 a.m. on November 13 in Japan), an Exchange Online mailbox connectivity failure was confirmed, and Microsoft began investigating it as "EX1550543." The problem was initially thought to be limited to users in the Americas, but its impact later expanded. At 1:26 p.m. US Eastern Time on November 12 (3:26 a.m. on November 13 in Japan), "MO1550821" was opened as a widespread outage spanning multiple services, and the notice on the Exchange Online connectivity problem was updated to say that users worldwide could be affected.
Thus, on November 12 US Eastern Time (late night on the 12th to early morning on the 13th in Japan), a standalone Teams outage was followed by a widespread outage centered on Exchange Online. Microsoft, however, has not said there is a causal relationship between the morning Teams outage "TM1550488" and the later "EX1550543" and "MO1550821." At this point, it is appropriate to treat them as separate incidents that happened on the same day.
The Cause Was a Loss of Servers, Not a Traffic Increase
As the investigation progressed, Microsoft's explanation of the cause changed. Initially, the company reported elevated load on infrastructure in multiple regions and examined whether traffic to certain services had increased unexpectedly. Later investigation, however, showed that the direct cause of the load increase was not a traffic surge.
Via its official X account "@MSFT365Status," Microsoft explained that a large number of servers had unexpectedly become unavailable, concentrating load on the remaining infrastructure. In other words, the volume of traffic to be processed had not spiked; rather, the number of servers able to handle traffic had fallen, placing excessive load on those still running. The company said it was working to safely restore the affected servers.
Further investigation revealed how the servers became unavailable. According to Microsoft, a core process for establishing secure communication connections became overloaded, causing affected servers to fail automated health checks. Health checks monitor whether servers are operating normally and remove them from traffic handling when an anomaly is detected.
In this outage, that mechanism removed servers from service one after another, concentrating even more load on those that remained. If the same problem occurs on servers that take on more load, processing capacity declines further. In this way, the detection and removal of unhealthy servers appears to have led to a cascading concentration of load. Health checks, meant to limit the impact of failures, ended up contributing to the reduction in available servers.
To stop this chain reaction, Microsoft froze new software deployments and configuration changes across infrastructure worldwide and redistributed traffic. In certain regions it partially restricted incoming traffic and began restarting the affected servers. It also tested alternative health-check methods so that server status could be judged appropriately.
However, restarting servers alone did not resolve the problem. Some servers that had recovered after a restart became unresponsive again once they began accepting traffic. This means that simply returning servers to an operational state was not enough; recovery required that they could keep handling normal traffic volumes. In addition to traffic redistribution and restarts, the cause of the load concentration had to be addressed.
Microsoft then focused on a recent network configuration change that coincided with the onset of the outage and began rolling back to the prior state. However, the fact that the timing of the change matched the outage and that a rollback was carried out is not enough to conclude that the change was the root cause. How the network configuration related to the server overload and health-check failures will have to await the final investigation results.
Some Servers Confirmed Recovered; No Timeline for Full Recovery Announced
In a status update at 6:57 p.m. US Eastern Time on November 12 (8:57 a.m. on November 13 in Japan), Microsoft reported that some affected servers had returned to normal and that signs of improvement were appearing in the service. The recovered servers were operating stably at that point, and traffic was being shifted to alternate paths. Procedures for recovering the remaining servers were also streamlined.
Even when servers recover, though, users cannot necessarily use every feature right away. Microsoft explained that recovery timing may differ by user as client applications attempt to reconnect. Even if server-side processing capacity is restored, a surge of connection requests can create a lag before users actually experience improvement.
As of the 6:57 p.m. US Eastern Time update on November 12 (8:57 a.m. on November 13 in Japan), no estimate had been given for when the service would be fully restored. The total number of affected tenants had not been disclosed, and no final report summarizing the root cause had been published.
In light of this outage, IT administrators at companies need to accurately grasp the scope of impact for each service. Microsoft 365 as a whole was not down, and some functions remained available, such as regular Teams messaging and online meetings and access to files in SharePoint Online. Moreover, no causal link between the morning Teams outage and the afternoon widespread outage has been confirmed at this point. Without taking this into account, it would not be appropriate to assume that all features were unavailable.
At the same time, the outage highlighted that dependencies inside the same group of cloud services can affect a wider range than expected. In addition to the loss of some Teams and SharePoint Online features that depend on Exchange Online, it is significant that the removal of servers through automated health checks led to load concentrating on the remaining servers. Attention now turns to whether restarted servers can remain stable while handling normal traffic, and how much the rollback of the network configuration change contributed to recovery.
When checking the impact on your own organization, do not rely only on external services such as Downdetector; consult the advisories for "EX1550543" and "MO1550821" posted in the Microsoft 365 admin center. If you cannot access the admin center, check the latest information on Microsoft's public status portal and verify individually which functions are actually usable.
The conditions under which this outage occurred and why so many servers became unavailable await Microsoft's final root cause analysis. In particular, the focus will be on how the network configuration change, the overload of the process responsible for secure connections, and the removal of servers by health checks were connected. Clarifying this will matter not only for preventing a recurrence in Microsoft 365, but also for assessing the reliability of cloud environments where multiple services depend on shared infrastructure.