A major Microsoft 365 outage that began in the early hours of November 13, 2026 (Japan time) continued to have an impact into the morning of the 14th. The incident record for the cloud email service Exchange Online began at 1:17 a.m. on the 13th. When checked around 7:00 a.m. on the 14th, it still showed no end time, meaning the recorded duration had reached about 29 hours and 40 minutes. Microsoft initially investigated increased load in multiple regions as the cause, but later revised its explanation, saying that some servers had unexpectedly become unavailable, which led to the higher load.
In the early hours of the 14th, Microsoft further stated that a problem created by a previous network capacity expansion had come to the surface after a recent network change. In its official status update, the company said it had addressed the cause, though recovery work was still continuing for some customers and regions at that point. The outage affected not only connections to Outlook and Teams but also email delivery, integrations with external AI services, and the operations of Japanese government agencies and companies.
Outage began in the early hours of the 13th in Japan and spread across multiple services
The outage is recorded as two incidents in Microsoft's administration system. "EX1550543," which indicates connection problems with Exchange Online, began at 1:17 a.m. Japan time on November 13. At 3:26 a.m., "MO1550821," an outage spanning multiple services, was recorded. Microsoft listed seven services that could be affected, including Exchange Online, Microsoft Teams, and SharePoint Online. It initially investigated the issue as one centered on the Americas, but later revised its explanation to say that users could be affected regardless of region. However, not all regions or users lost access to the services, and the total number of affected users has not been disclosed.
The scale of the outage is also reflected in the number of user reports. According to Reuters, Outlook problem reports on the outage-tracking site Downdetector peaked at 138,058 around 3:00 a.m. Japan time on the 13th, then fell to about 34,490. Even shortly before 8:00 a.m. that day, there were about 13,000 reports for Microsoft 365 overall and 763 for Teams. These figures, however, are numbers of reports submitted by users and do not indicate the number of people actually affected.
In Japan, the outage coincided with the start of the working day on Friday and disrupted the operations of companies and government agencies. The Japan Times cited posts on social media from employees who could not open Outlook and had to rearrange meetings, and from people who said their bosses told them to stay home, and also reported that fax machines drew renewed attention as a means of communication. Connection problems with Microsoft 365 were also confirmed at universities in Japan, and Hitotsubashi University on the 13th warned that the login screen could appear repeatedly. The university advised users not to change settings or reinstall apps and to try again after the service recovers.
Server recovery proved difficult, rooted in a problem from an earlier network expansion
When the outage began, Microsoft explained that traffic load was increasing in multiple regions. However, subsequent investigation showed that the rise in load was not caused by a surge in user access but was the result of some servers unexpectedly becoming unavailable. The company confirmed that health checks were failing on the affected servers and investigated whether a specific component responsible for that process was involved. When servers can no longer continue processing, load concentrates on the remaining servers, so the outage may have spread in a chain reaction.
In fact, the initial recovery measures did not have the expected effect. According to Microsoft, a core process on the affected servers was overloaded and unable to handle requests. Mynavi News reported that servers that had once recovered stopped responding again when they resumed communication, and that calls to backend servers surged. Microsoft added virtual machines and repaired servers, and also took steps to prevent additional servers from dropping out of service. However, restoring server processing capacity alone did not keep the system stable.
According to Microsoft outage information published by the University of Wisconsin–Milwaukee (UWM), an update at 10:06 a.m. on the 13th said that the process of establishing secure connections was overloaded, leaving the affected servers unable to handle user requests. Microsoft tested a configuration change as a countermeasure on some servers and prepared to expand its application in combination with server restarts. At the same time, it began work to revert the recent network configuration to its previous state. According to BleepingComputer, it was also examining whether halting all new deployments and rolling back some recently applied settings could speed recovery.
Later, in its official announcement in the early hours of the 14th, Microsoft explained that a problem arising from a past network capacity expansion had surfaced because of a recent network change. The company said it had addressed the problem that caused the outage and was proceeding with recovery while confirming stability at each stage, taking the large scale of usage into account. This revealed not only the server overload and unavailability that were initially seen as the problem but also the network configuration issue behind them. However, detailed explanations are still awaited on what exactly went wrong during the earlier capacity expansion and how the recent change triggered the outage.
Microsoft also stated that it has found no sign of malicious activity or a cyberattack in this outage. Based on the information published so far, it appears that a network configuration problem and the resulting decline in server processing capacity made recovery difficult. How much these factors contributed to the prolonged outage will need to be verified in a post-incident report.
Connectivity improved in Japan on the night of the 13th, but email delivery delays continued
In an update published at 9:00 p.m. on the 13th, Microsoft said connectivity in Japan was relatively stable, and improvement was also seen in Europe and North America. However, intermittent problems could still occur in some regions, and the company was prioritizing the processing of queued email. The email delivery retention period was extended to 48 hours, a measure continued to reduce the risk that delayed messages would expire and be lost.
At 11:01 p.m. the same day, it was reported that queued email was decreasing and approaching normal levels. However, an update at 11:55 p.m. still said that some users might experience intermittent connection drops or delayed email arrival. In other words, even when users could open Outlook and check email again, it was not certain that all messages sent during the outage had reached their recipients. Microsoft also reported the recovery of connectivity and the delivery of backed-up email separately, indicating a time lag between the normalization of the two.
In the incident records checked around 7:00 a.m. on the 14th, no end time was listed for either the Exchange Online incident "EX1550543" or the multi-service incident "MO1550821." By calculation, about 29 hours and 40 minutes had passed since the start of the former and about 27 hours and 30 minutes for the latter. However, an incident record remaining open does not mean that all users were unable to use the service the entire time. Recovery status varied by region and service, and even after Microsoft announced it had addressed the cause, work continued to resolve remaining problems and email delivery delays.
Outage spread to Microsoft 365 integrations in Claude and ChatGPT
The outage was not limited to Microsoft 365's standard email and chat functions; it also affected features that let external AI services use Microsoft 365 information.
According to an incident report published by Anthropic, errors affected Claude's Microsoft 365 integration from 1:03 a.m. on November 13 to 1:40 a.m. on the 14th Japan time, a total of 24 hours and 37 minutes. During this period, many requests to retrieve email and calendar information or search related information through the Microsoft 365 connector produced errors. "Claude for Outlook," which lets users use Claude within Outlook, was also affected.
In a monitoring report at 12:40 a.m. on the 14th, Anthropic said some errors remained in SharePoint search. It then announced at 6:49 a.m. that the impact period had ended, while cautioning that intermittent errors and delays could occur while Microsoft's recovery continued. The figure of 24 hours and 37 minutes is calculated from the start and end times of the impact period that Anthropic presented after the fact, and differs from the time taken until the announcement of recovery completion.
OpenAI also reported that connectors and apps used to access Microsoft 365 information and functions from ChatGPT were affected. According to OpenAI's incident information, at 3:29 a.m. on the 13th it was investigating problems with establishing new connections and using connected tools. At 1:20 a.m. on the 14th, signs of recovery were confirmed, and the company said it was continuing to monitor progress.
These cases show that a Microsoft 365 outage can spread to external services. Even if the AI service's own inference functions have no problems, features that rely on connected email, calendar, and document management systems will not work properly if those systems cannot be reached. For companies building AI assistants into daily operations, the availability of connected services matters as well as model performance.
Government agencies, logistics and airport operations affected in Japan
In Japan, a series of organizations changed how they handled regular inquiries and reservations because of the Microsoft 365 outage.
The Financial Services Agency announced on the 13th that it was unable to send and receive email and might not have received messages sent that day. It switched to accepting inquiries by phone and said it would treat the day it received a call as the date of receipt. The Consumer Affairs Agency also said that day that it could not send or receive email and urged people to contact it by phone. With such measures, the date and time a user sent an email may differ from the date an inquiry was formally accepted.
In logistics, there were cases where being unable to use email prevented online procedures from being completed. According to TV Asahi's report, Sagawa Express suspended internet reservations for some services, such as temporary baggage storage at stations and airports. Because it could not send reservation confirmation emails, it reportedly told customers to fill out paper forms at the counter. This is an example of an email outage affecting business procedures themselves, such as confirming a reservation.
Haneda Airport Passenger Terminal also announced on the 13th that it could not reply to some inquiries by email. It said it would respond in order after recovery, but that this might take longer than usual. Even after email sending and receiving is restored, the backlog of inquiries that accumulated during the outage remains to be handled, so it may take additional time for operations to return fully to normal.
What these domestic cases have in common is that the Microsoft 365 outage affected not only means of communication but also business procedures such as receipt dates, reservation confirmations, and replies to inquiries. For government agencies in particular, the date an inquiry is received can be important, so the challenge lies not only in preparing alternatives but also in deciding how to treat business conducted in the interim.
What to watch: details of the network change and why recovery dragged on
Microsoft has indicated that it will publish a post-incident report on the outage. The biggest question is why the problem from the earlier network capacity expansion had been left in place, and what conditions changed because of the recent network change. It will also be important to learn how the failed server health checks and the phenomenon of recovered servers becoming unresponsive again were related to the network configuration problem.
Several possibilities remain open regarding why the outage dragged on. Servers repeatedly becoming unavailable likely hindered recovery, but it is unclear how much the time needed to roll back settings or other factors contributed. If Microsoft's post-incident report attributes the prolonged outage mainly to another factor, the assessment of events here will need to be revisited.
The period during which the incident records were open included all of the typical Japanese business hours, 9:00 a.m. to 6:00 p.m., on Friday, November 13. This does not mean all users were without service for the whole day, but it is certain that companies had to wait for a recovery outlook for more than one business day.
In addition, in this outage the time when users could reconnect to the service and the time when the backlog of queued email was cleared did not necessarily coincide. If the post-incident report clarifies regional connectivity recovery times and email delivery normalization times, the time required for recovery can be assessed more accurately. With Microsoft 365 now serving as the foundation not only for corporate communications but for a wide range of business systems, including AI services, attention will be on how specifically the company explains the cause of this outage and its measures to prevent a recurrence.