A large number of Microsoft’s own servers dropped out of service on Thursday, November 12, 2026, cutting off Outlook, Teams, SharePoint Online and Copilot for users across the Americas and, by Friday morning, Australia. As of about 7:15 p.m. Eastern Time (ET), Microsoft had not declared the outage over and had not published a root cause. A company spokesperson told the Australian Broadcasting Corporation (ABC) there was “no indication this is a cyber attack.”
How the Outage Unfolded
Trouble started in the morning, when Microsoft said it was investigating problems with Teams for users in North America. The company later said its mitigation had restored that service, and it has not said whether that incident is related to the larger one. The larger failure arrived in the early afternoon. Variety reported that user complaints about Outlook began spiking around 12:39 p.m. ET, and at 12:54 p.m. the Microsoft 365 Status account on X acknowledged that users were struggling to reach Exchange Online mailboxes in the Americas.
Microsoft tracked the mailbox problem as incident EX1550543 and opened a wider advisory, MO1550821, which BleepingComputer reported as starting at 1:26 p.m. ET. That advisory named Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR. As the afternoon went on, the list grew. Forbes Australia’s tally added Planner, To Do, Intune, Defender for Office 365, Purview, Power BI and the Microsoft 365 Apps admin center. Microsoft also warned that the problem could affect connectivity for users in any region.
Scale is hard to pin down. Downdetector counts user-submitted reports rather than affected accounts, and it recorded 138,058 Outlook reports around 1 p.m. ET, according to Reuters. Fox Business, citing Dynamics Connect, put Microsoft 365’s user base at roughly 321 million, though that is a third-party estimate.
What Microsoft Says Went Wrong
Microsoft’s explanation shifted as the day went on, which is normal in a live incident and worth reading closely. The first public diagnosis was elevated load on part of its infrastructure across multiple regions. Microsoft then refined that. The load, it said, was not coming from extra traffic but from “a number of servers being unexpectedly unavailable,” which strained the machines still running. It said it had paused deployments, was moving traffic off the affected infrastructure and was restarting servers. Soon after, it tied the unavailable servers to failed automated health checks.
In mid-afternoon Microsoft said it had found no recent change that lined up with the start of the impact, but that the failed health checks might come from a specific component that processes server health. It began deploying a change to bypass that component on a subset of servers and started looking into why the affected servers showed elevated processor usage. Around 4 p.m. ET, CNBC reported, Microsoft said an alternative health check method had let some servers return to service, and it began applying the method more broadly.
Microsoft added two details over the following hours. It said a small number of configuration updates were under investigation as potential contributors and, by about 5 p.m. ET, that a core process on the affected servers was becoming overwhelmed. The first detail sits awkwardly beside the earlier statement that no recent change matched the start of the impact. The two can be reconciled, since a configuration update may contribute to a failure without lining up with its first minute, but Microsoft has not yet explained how those updates relate to the health check component.
Progress was uneven. Microsoft said its actions so far had not provided the relief it expected. By about 6 p.m. ET it reported that a portion of the affected servers had returned to service and were holding stable, and it told users to expect a gradual recovery as their clients reconnect. Reuters reported that Outlook reports on Downdetector had fallen to about 34,490 by evening. A falling count is not the same as a working inbox: TechRadar’s live coverage noted at roughly the same hour that access had not returned for everyone, or even for most users.
Then came a setback. By about 7:15 p.m. ET Microsoft reported, as ABC’s live coverage relayed, that servers it had brought back could become unresponsive again once they started taking traffic. It responded by limiting which types of traffic could reach the affected infrastructure in some locations, and by rebuilding a subset of servers on a previous software configuration to test whether that stops them becoming unresponsive.
Why Recovery Was Slow
This section is analysis, not a diagnosis Microsoft has confirmed. Microsoft’s updates describe a loop that is familiar in large server fleets. When health checks pull servers out of rotation, the remaining servers absorb their traffic, and each further loss raises the load on the survivors. Restarting machines helps only if they can withstand the traffic that returns to them, and that is exactly where Microsoft reported trouble.
Mark Gregory, an associate professor at RMIT University in Australia, offered a similar reading to the ABC. Many servers appeared to have dropped off the list of available servers, he said, leaving the rest unable to carry all the traffic. If that reading is right, a restart is not a recovery. Engineers have to rebuild capacity gradually and throttle demand while they do it, which is consistent with Microsoft’s decision to restrict some traffic types.
Who Felt the Outage
In the US, the Michigan Department of Technology, Management & Budget said state government was having trouble with email and other Microsoft apps. Michigan Medicine reported problems reaching Outlook and other Microsoft applications, and sources told The Detroit News that Henry Ford Health lost access to Outlook and Teams. In Canada, CP24 reported that a Toronto hospital network declared a “Code Grey,” the designation for a loss or failure of infrastructure, and that Via Rail services were affected.
In Australia, where the outage arrived on Friday morning, Service NSW reported that some transactions at its service and call centres were unavailable. According to the Australian Associated Press, NSW Parliament, the Australian Capital Territory and Northern Territory governments, local councils and Queensland Health were also affected. A Home Affairs spokesperson said Australia’s National Cyber Security Coordinator, Lieutenant General Michelle McGuinness, was looking into the outage.
Reuters reported at least one direct business consequence: the US electric truck maker Workhorse Group moved its third-quarter results announcement from November 12 to November 16, citing business disruption from the outage. Sign-in problems added a second layer of pain. ABC reported that some users said the Outlook failure also locked them out of other services because they could not use two-factor authentication codes to log in.
AI Assistants Inherited the Outage
Copilot sat on the advisory’s list of affected services, and the damage reached beyond Microsoft’s own assistant. Reuters reported that the outage also hit connectors used by OpenAI’s and Anthropic’s AI services. OpenAI said new connections to Microsoft connectors might be broken and that tools might not work as expected. Anthropic said an issue with an upstream provider was affecting its Microsoft 365 connector.
The implication is that an AI assistant connected to a mailbox is only as available as the mailbox. When Exchange Online fails, an agent that drafts replies, summarizes threads or schedules meetings has nothing to read and nothing to act on, whichever company built the agent. Companies that have layered AI features on top of Microsoft 365 should count Microsoft’s availability in their AI risk assessment as well as their IT risk assessment.
What the Outage Was Not
Downdetector also showed spikes for Azure, but Microsoft’s advisory for the incident did not list Azure among the affected services. CNBC reported that Amazon Web Services said it was operating normally and flagged inaccurate outage reports on its platforms, while Tom’s Guide saw reports appear for Gmail, Zoom and Yahoo Mail. One plausible explanation, though not one the trackers confirm, is that people check other services when a dominant one fails, which inflates report counts elsewhere.
On the question of an attack, Microsoft has said there is no indication of one. Its own description, a loss of server capacity under ordinary demand rather than an overload of traffic, is also not what a flood-style attack typically looks like.
A Pattern in How Microsoft’s Outages Begin
Thursday’s failure fits a run of incidents in which Microsoft’s own accounts point inward. On October 29, 2025, an Azure Front Door outage degraded Microsoft services and customer sites from 15:45 UTC until 00:05 UTC on October 30. Microsoft confirmed an inadvertent configuration change as the trigger. On January 22 and 23, 2026, The Register reported, Microsoft 365 was disrupted for nearly 10 hours, and Microsoft blamed part of its North American infrastructure for not processing traffic as expected. Tom’s Guide reported that Microsoft also cited elevated service load combined with temporary capacity constraints during maintenance.
On July 23, 2026, according to BleepingComputer, a bug in the system that converts maintenance requests into machine-readable instructions wrongly tagged extra network devices, and routes were removed from more devices than intended in Microsoft’s West US region. Microsoft rolled the change back, and services were fully restored by 3:41 p.m. ET. On the Azure side, Microsoft’s status history records that from 20:30 UTC on September 30 to 02:15 UTC on October 1, several Azure networking services returned intermittent failures on management operations as a rolling update moved through the regions. The impact ended once Microsoft finished rolling back a change that had increased control plane processing time.
In each of those four cases, Microsoft’s own account points to its internal change, maintenance or capacity handling rather than an outside attack. Thursday’s cause is unconfirmed, so adding it to the list would be premature. Microsoft’s references to a health check component and to configuration updates under investigation point in the same direction.
What IT Leaders Should Take From It
Keep an incident channel that does not run on the suite that is failing. During Thursday’s outage Microsoft pointed administrators to status.cloud.microsoft for details when the admin center was unavailable, and ABC10 reported that the status page itself had loading errors at one point. A team that coordinates its response in Teams and Outlook has no coordination at the moment it needs it most.
Map which sign-ins depend on a mailbox, because lockouts compounded the damage for some users. Then ask each AI vendor in your stack which Microsoft connectors its agents rely on, and write down what the business does by hand when those connectors stop.
What to Watch Next
As of Thursday evening, Microsoft had not published a post-incident review for the outage. When one arrives, three answers will matter most: why servers failed their health checks, why restored servers froze again under traffic, and what the configuration updates under investigation actually changed. After the July incident Microsoft said it would review its safety checks and its maintenance automation, so the test this time is whether the review names a cause specific enough to prevent a repeat.
The post Microsoft 365 Outage: Failing Server Health Checks Took Down Outlook, Teams and Copilot appeared first on DataFLOQ.
