Inside the Outlook Outage: How a Server Failure Cascaded Across Microsoft 365

Microsoft says an overloaded process and unavailable servers have disrupted Exchange Online, with effects reaching calendars, collaboration tools and security features. A network change is under investigation, but the initiating cause remains unconfirmed.

November 12, 2026 — Updated with Microsoft’s 9:54 p.m. Eastern incident report

A widespread Microsoft 365 disruption that began Thursday left many users unable to reach Outlook mailboxes, delayed some email delivery and affected features across a range of other Microsoft services. By Thursday night, Microsoft was still working to restore capacity after finding that servers handling connections had become unavailable and that a process responsible for establishing secure connections was becoming overwhelmed.

The company’s latest available Exchange Online update said a change intended to improve service had not taken effect as expected. Microsoft was examining other ways to increase capacity as traffic remained unevenly distributed across affected infrastructure. It had not declared the incident resolved or identified a definitive root cause. University of Pennsylvania’s public extract of Microsoft incident notices

The failure has been widely described as an “Outlook outage,” but Outlook is the visible part of a larger system. The principal incident concerns Exchange Online, Microsoft’s hosted email and calendar service. When the infrastructure accepting connections to that service became unavailable, the effects reached far beyond a single desktop application—and exposed how many everyday functions depend on the same underlying services.

The disruption was broad enough to generate nearly 130,000 Outlook problem reports on Downdetector shortly after 1 p.m. Eastern, according to the Associated Press. That number measures reports submitted to the tracking service, not a verified count of affected customers, organizations or individual users. Associated Press

What failed

Microsoft is tracking the mailbox incident as EX1550543 and the broader effects on Microsoft 365 as MO1550821. Its records list the start of the Exchange incident at approximately 11:17 a.m. Eastern Thursday.

The company initially observed elevated load on infrastructure that receives and processes requests to access mailboxes. As its investigation progressed, Microsoft said the load was not the result of an overall increase in incoming traffic. Instead, a large number of servers had become unexpectedly unavailable, shifting work onto the infrastructure that remained.

Microsoft subsequently identified failures in automated health checks. Those checks are used to assess whether infrastructure is available to handle work. In this incident, affected servers were failing the checks and becoming unavailable, reducing the capacity available to process connections.

Later, Microsoft reported that a process on affected servers responsible for establishing secure connections was becoming overwhelmed. The servers could stop processing requests as a result. The company began testing a configuration change aimed at that behavior and started reverting a recent network configuration change that correlated with the beginning of the impact.

That correlation is an investigative lead, not a confirmed finding that the network change caused the outage. Microsoft’s incident record still listed the root cause as unavailable in its 9:54 p.m. Eastern update. Microsoft incident notices, reproduced by the University of Pennsylvania

The sequence of the disruption

Microsoft’s updates show how its understanding changed as engineers investigated:

• 11:17 a.m. Eastern: The Exchange Online incident began, according to Microsoft’s recorded start time. Users could encounter errors or failures accessing mailboxes.
• Early afternoon: Microsoft identified connectivity errors in infrastructure that receives and processes mailbox access requests. It began examining service and networking data.
• 2:29 p.m.: The company said it had redirected some traffic away from affected U.S. infrastructure and was evaluating similar action elsewhere. Microsoft also acknowledged connectivity problems involving additional Microsoft 365 services.
• 3:18 p.m.: Microsoft said the elevated load was being driven by unavailable servers shifting work to the remaining infrastructure, rather than by an overall increase in traffic.
• 3:43 p.m.: Microsoft said affected servers were failing automated health checks and that it was testing a configuration change on a subset of infrastructure.
• 3:56 p.m.: An alternative health-check method had allowed some servers to return to service. Microsoft began applying the change more broadly while investigating a small number of configuration updates as possible contributors.
• 5:57 p.m.: Microsoft reported limited recovery in some regions and said it was shifting connections to alternative paths where possible.
• 6:59 p.m.: The company said some restarted servers initially appeared healthy but became unresponsive again after receiving traffic.
• 8:06 p.m.: Microsoft identified the overwhelmed secure-connection process and said it had begun reverting a network configuration change that correlated with the onset of the incident.
• 9:54 p.m.: Microsoft said its latest serviceability change was not taking effect as expected and that it was investigating alternative ways to increase capacity.

The timeline reflects the reports available at those times. It does not establish that every affected user experienced the outage continuously or that every recovery measure failed everywhere. Microsoft described some regional improvement before its later update identified continued problems. Microsoft incident history

Why restarting servers did not immediately restore service

The distinction between a server being switched on and a service being healthy under real traffic became central to Microsoft’s recovery effort.

A restarted server can initially pass checks when it is handling little work. In this incident, Microsoft observed that some servers became unresponsive again once requests returned. That meant engineers could not judge recovery solely by whether machines had restarted or temporarily reappeared as available.

Microsoft responded by isolating portions of infrastructure, restarting components and gradually reintroducing traffic. It also limited certain types of traffic in specific locations to observe whether servers remained stable under a narrower workload. At one stage, the company rebuilt a subset of affected servers using an earlier software configuration to test whether that would prevent them from becoming unresponsive.

These steps address different pieces of the same problem. Restarting can bring a system back temporarily; limiting or redirecting traffic can reduce pressure; changing a configuration may address the behavior that makes the system fail again. Microsoft’s updates do not yet establish which measure, or combination of measures, will produce a durable recovery.

The incident also illustrates a difficult capacity problem. When servers drop out, their work does not necessarily disappear. It can move to the remaining servers, increasing pressure on infrastructure that is still operating. If recovered servers cannot sustain renewed traffic, restoring capacity becomes slower and more complicated. That describes the failure pattern Microsoft reported; it does not by itself explain the original trigger. Microsoft incident history

Outlook is the front door; Exchange is the service behind it

Outlook is commonly understood as an email application, but it can be used through several interfaces: a desktop program, a web browser and mobile devices. Exchange Online is the hosted service that provides the underlying mailboxes and associated calendar, contacts and task functions.

Microsoft describes Exchange Online as a messaging service hosted in its datacenters and accessible from PCs, the web and mobile devices. The company’s incident notice identified several potentially affected connection methods, including Outlook on the web, the desktop connection method known as MAPI, Exchange ActiveSync and REST-based connections. Microsoft Exchange Online service description

That distinction explains why a user could encounter a similar problem after switching from the Outlook desktop application to a browser or phone. The interfaces differ, but they may be trying to reach the same affected mailbox service.

It also explains why symptoms were not necessarily identical. Depending on the connection, account and portion of infrastructure involved, a user might see an inbox fail to load, an application stop synchronizing, an operation time out or a message remain unsent. Microsoft’s notice described these connection methods as potentially affected; it did not say every method failed for every customer.

The effects extended beyond email

Microsoft’s broader incident notice described problems in functions that interact with Exchange Online and email. Its list included possible mailbox access failures and delayed mail delivery, as well as effects on Microsoft 365 administration and other applications.

The distinction between an affected feature and an entirely unavailable product is important.

For Teams, Microsoft said scenarios depending on Exchange Online—including calendars and meeting scheduling—could fail, while core messaging and online meetings remained largely functional. A person might therefore be able to join an existing meeting or exchange messages while seeing an incomplete calendar or encountering trouble scheduling another meeting.

For SharePoint Online, Microsoft said functions dependent on Exchange could be affected, while direct access to files stored in SharePoint remained functional. Microsoft also listed potential effects involving Copilot’s access to work data, Microsoft Graph requests involving mail and calendars, Planner tasks, and some security and compliance functions. The exact experience depended on which feature and infrastructure a customer was using. Microsoft 365 incident notice, reproduced by the University of Pennsylvania

Earlier Thursday, Microsoft also dealt with a separate Teams incident, tracked as TM1550488, which it reported resolved before the later, broader disruption. The fact that the earlier Teams incident was restored did not mean the Exchange incident and its related Microsoft 365 effects were resolved. BleepingComputer’s incident reporting

Was email lost?

Microsoft’s broader notice said email delivery could be delayed. A delay, however, does not establish the ultimate disposition of every message.

Email travels through multiple systems. A message can remain in an application’s outbox, be accepted by a sending service and wait for delivery, reach the recipient’s mail service but remain inaccessible through the recipient’s client, or be returned to the sender if delivery ultimately fails. Which outcome applies depends on where the message was in the process and how the organizations’ systems handled it.

A mailbox that cannot be opened is therefore not proof that its contents have been deleted. Equally, a message that appears to have left a sender’s screen is not, by itself, proof that the recipient received or read it.

The information Microsoft had released by Thursday night did not support a blanket conclusion that messages were permanently lost or that every delayed message would eventually arrive. Those are separate questions from whether mailbox access and service connectivity have recovered. Microsoft 365 incident notice

The government and military distinction

The outage is relevant to organizations that depend on Microsoft’s cloud services, including government agencies and contractors. But public reports about commercial Microsoft 365 do not, on their own, establish that a particular military command, installation or government tenant experienced this incident.

Microsoft offers distinct GCC High and Department of Defense environments for eligible organizations, with requirements and service characteristics that differ from general commercial offerings. A public incident report may not describe the status of every government environment, organization, account or connection. Microsoft’s description of GCC High and DoD environments

The distinction cuts both ways. A commercial outage report should not be treated as confirmation that a DoD mailbox is affected. Nor does the existence of separate government environments establish that every service, external correspondent or connection used by a government organization is unaffected.

For organizations exchanging information with outside partners, the effect can also arise on the other side of a communication. An internal mailbox might be available while a contractor, civilian agency or other correspondent is unable to retrieve or send a message. That is a possible consequence of the architecture and the reported disruption; the available public evidence does not establish that it occurred at any particular command.

The operational picture is broader than an inbox

The outage demonstrates how a single messaging service can sit underneath several different kinds of work.

Email carries correspondence, but the same environment can also support calendar invitations, contacts, automated notifications and applications that retrieve mailbox data. When those functions share infrastructure, a degradation can appear in several places at once: a scheduling feature fails, a notification is delayed, a workflow cannot retrieve a mailbox item, or an administrator cannot load the page used to investigate the problem.

That does not mean each of those failures occurred for every customer Thursday. It does explain why the scope of a service incident can be wider than the name of the product most users see.

It also complicates the meaning of “back up.” A user may regain access to an inbox before delayed messages have arrived. A Teams conversation may work while calendar integration remains unreliable. A restarted server may appear healthy before it is exposed to its normal workload. Recovery can occur in stages, and the disappearance of one symptom is not necessarily confirmation that every dependent function has stabilized.

Questions still unanswered

Several material questions remained open in Microsoft’s latest available updates:

• What initiated the failure? Microsoft identified an overwhelmed process and was investigating a network configuration change, but had not established a final root cause.
• How many customers were affected? Public outage-reporting figures show the scale of complaints submitted to a tracker; they do not provide a verified count of affected people or organizations.
• Which environments and regions were affected, and for how long? Microsoft described varying impact and limited recovery in some areas, but the public information reviewed did not establish a complete customer-by-customer picture.
• What happened to individual delayed messages? Microsoft acknowledged possible delivery delays; final disposition depends on the path and systems handling each message.
• When will service be fully restored? Microsoft had not declared the Exchange incident resolved in the latest update reviewed for this article.

The most consequential finding so far is not that an email application malfunctioned. It is that a failure affecting the infrastructure used to establish and handle connections reduced available capacity, placed additional load on the remaining system, and disrupted a collection of services built around Exchange Online. Microsoft had identified important parts of that chain by Thursday night; the question of what set it in motion remained under investigation.

DutyStation News prepared this AI-assisted article using the linked public sources.