On November 14, 2026, Microsoft announced that it had finished restoring service to the customers and regions still affected by the global Microsoft 365 outage. Recovery had progressed across a wide area on the 13th, but work continued in some places. The latest announcement marks the shift from that stage to completed recovery.
In Japan, the Tokai National Higher Education and Research System recorded the recovery time of the same outage as 1:10 p.m. Japan time on the 14th. In Microsoft's updates, restoring connectivity, working through mail queued for delivery, and restoring service for the remaining customers and regions were separate stages. What happened before recovery was complete, and what remains unexplained about the cause?
Full recovery announced, with a recorded duration of 33 hours 44 minutes
In an official post on the 14th, Microsoft 365 Status announced that it had "restored service to the customers and regions that were still affected." It pointed readers to incident number MO1550821 in the Microsoft 365 admin center for detailed updates. Following the broad recovery on the 13th, the post announced that recovery was complete for the remaining customers and regions as well.
The Tokai National Higher Education and Research System listed the duration of MO1550821 as 33 hours 44 minutes, from 3:26 a.m. on November 13 to 1:10 p.m. on the 14th. The system's record is in Japan time: 24 hours from the start to the same time the next day, plus 9 hours 44 minutes until 1:10 p.m. This figure is the outage period posted by the system. It does not represent a time during which users around the world were uniformly and continuously unable to work.
The system listed Exchange Online, the Microsoft 365 suite, Microsoft Copilot, Microsoft Defender XDR, Teams, and SharePoint Online as affected services. Within the system, it confirmed that email could not be sent or received and that Outlook could not be launched. It said some Teams and SharePoint functions became unavailable.
XenoSpectrum's morning report on the 14th covered the recovery work under way during the outage and its impact in Japan. Microsoft then announced recovery for the remaining customers and regions, and the system's record also gained an end time.
A past capacity expansion problem surfaced after a later change
The outage history published by the University of Wisconsin–Milwaukee (UWM) reproduces Microsoft's updates. In one of them, at 11:57 a.m. Central Standard Time on the 13th, the company explained that an issue from a past network capacity expansion had surfaced following a later network change. At that point, it said, it had addressed the cause and was working to restore customers and regions that were still affected.
According to Microsoft's earlier updates, a server process that establishes secure connections had become overloaded and could not handle requests. The company validated configuration changes on some servers, prepared to deploy them in parallel with restarts, and began work to roll back recent network configuration changes.
However, simply bringing servers back did not stabilize the situation. Microsoft explained that servers that were healthy immediately after returning to service could stop responding again once they received traffic. It therefore limited the types of traffic and rebuilt some servers with a previous software configuration. In its update at 12:56 a.m. Central Standard Time on the 13th, it reported that it had also added virtual machines.
Recovery involved not only restoring processing capacity but also confirming that the restored environment stayed stable under real demand. Microsoft said it took time because it verified stability at each stage, given the scale of demand.
Connectivity and mail delivery recovered at different times
Even once the service can accept requests to send and receive email, the work of processing mail queued for delivery during the outage remains. Microsoft's update at 5:01 a.m. Japan time on the 14th, reproduced by the Tokai National Higher Education and Research System, explained that restored connectivity and normalized mail flow do not necessarily happen at the same time.
According to the same posting, the 11:17 a.m. Japan time update was still tracking service degradation and the processing of accumulated mail. In the 1:17 p.m. Japan time update, Microsoft described service as restored. The 1:10 p.m. recovery time recorded by the system itself and the timing of Microsoft's updates are separate records.
In the update reproduced in UWM's outage history for 6:00 a.m. Central Standard Time on the 13th, Microsoft assessed that availability and delivery performance had improved in Europe, that Japan was relatively stable, and that North America was also improving. At that point Microsoft was prioritizing reducing the mail queue and maintaining a measure that extended timeouts to 48 hours to protect delayed messages. The 48 hours is a waiting period intended to protect delayed mail.
In its update at 8:01 a.m. Central Standard Time the same day, it said the queue was approaching normal levels, though intermittent failures and mail delays might remain in some cases. Regional recovery, the clearing of queues, and the status of individual users did not progress at the same speed. The final announcement on the 14th shows that the recovery had reached the stage of restoring service to the remaining customers and regions.
Next focus: change management and an explanation of how to prevent a recurrence
In its explanation at 11:57 a.m. Central Standard Time on the 13th, reproduced by UWM, Microsoft described the incident as a technical problem and ruled out any connection to a cyberattack, AI, or agents. The company said that once its investigation is finished, it will provide a post-incident report, including the root cause and improvements to its layered defenses.
The current explanation does not yet make clear the specific path: what problem arose during the past capacity expansion, how a later network change caused it to surface, and how that led to the overload of the process responsible for secure connections.
During recovery, servers that regained responsiveness after a restart sometimes stopped responding again when they received traffic. The post-incident report will be a basis for judgment on two points: at what stage anomalies can be caught when changes are applied, and how Microsoft verifies that stability holds when traffic is returned during recovery. Restoring service while limiting the impact of an outage requires measures that are effective at both stages.