AI Infrastructure // DEPENDENCY

Outlook and Copilot Went Down Together. Microsoft Has Not Said AI Was the Cause

An Exchange Online outage took Outlook, Teams, SharePoint and Microsoft 365 Copilot offline for hours on Thursday. Microsoft's own incident records describe overloaded servers, a process that handles secure connections becoming overwhelmed and a network configuration change the company has begun reverting, and name no AI workload as the cause.

A widespread Microsoft 365 outage left users unable to reach their mailboxes for hours on Thursday, and the company's own status updates place the failure inside its server fleet rather than in anything those servers were being asked to do with artificial intelligence.

Exchange Online began degrading at 16:17 UTC (11:17 a.m. Eastern), according to Microsoft's incident record EX1550543. The broader Microsoft 365 incident, MO1550821, opened at 18:26 UTC (1:26 p.m. Eastern) and covers the knock-on impact across other services. Neither incident had ended at the time of writing, and both remained classified as service degradations rather than resolved.

What Microsoft says failed

The Exchange Online record is titled, in Microsoft's words, “Users may be unable to connect to their mailboxes in Exchange Online through multiple connection methods”. The potentially impacted routes it lists are Outlook on the web, the Messaging API known as MAPI, Exchange ActiveSync and the REST API.

By 22:00 UTC Microsoft had identified a mechanism. Its update states that “a core process on the affected servers is becoming overwhelmed, which causes the servers to stop responding and contributes to the capacity loss”. Earlier the same afternoon the wider Microsoft 365 record, MO1550821, had described the visible symptom as “elevated load across multiple regions, which is likely contributing to the connectivity errors”, and the Exchange Online record had already said the load was “contributing to the connectivity errors users are receiving”. Both are earlier statements, and both are hedged about mechanism.

Those two statements describe a cascade rather than a single fault. Servers stopped responding, capacity fell, and the servers still working absorbed the traffic. Microsoft's own update states that “the elevated load isn't driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable”, while an earlier update said it was “reviewing an unexpected increase in a specific type of service traffic” to establish whether one kind of request was contributing. SecurityWeek's reporting, which attributes the no-increase finding to Microsoft, is consistent with the record.

At 01:06 UTC on 13 November Microsoft narrowed the mechanism further, and this is the most specific cause-adjacent statement it has released. Its update states that “a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests”. The same update says the company has “begun reverting a recent network configuration change that correlates with the start of impact”. It is monitoring to determine whether the revert contributes to recovery.

Two things should be kept apart in that sentence. A correlation with the start of impact is a timing relationship, which is a reason to revert a change and watch what happens. It is not a declaration that the change caused the outage, and Microsoft has not made one. Earlier, at 19:57 UTC, the Exchange Online record said: “we haven't identified any recent changes that correlate with the start of impact”. Both statements are accurate as of their own timestamps, and the difference between them is an investigation moving, not a record contradicting itself.

The recovery path ran into the same problem repeatedly. At 20:38 UTC Microsoft reported that “many of the affected servers have become unresponsive, which is preventing us from confirming whether the change is effective”. It validated an alternative health check method, and said it was preparing an automated process to detect and restart unresponsive servers. It also said it was rebuilding a subset of affected servers using “a previous software configuration” and would widen that approach if it worked.

The timeline, UTC and Eastern

16:17 UTC / 11:17 a.m. ET: Exchange Online begins degrading. 18:26 UTC / 1:26 p.m. ET: the wider Microsoft 365 incident opens. Mass user reports on the outage tracker Downdetector peaked at nearly 130,000 just after 1 p.m. ET, according to the Associated Press.

18:19 UTC / 1:19 p.m. ET: Exchange Online reports elevated load across multiple regions that is contributing to connectivity errors. 19:57 UTC / 2:57 p.m. ET: Microsoft says the failed health checks may originate from a specific component on the affected servers, that it is deploying a change to bypass that component, and that it has not yet identified any recent change correlating with the start of impact; it also opens an investigation into elevated processor usage. 20:38 UTC / 3:38 p.m. ET: servers unresponsive, blocking validation of the fix. 20:56 UTC / 3:56 p.m. ET: an alternative health check method is validated on a subset and Microsoft says it is preparing automated restarts. 21:31 UTC / 4:31 p.m. ET: Microsoft says it is assessing whether reverting a small number of recent configuration updates would speed recovery.

22:00 UTC / 5:00 p.m. ET: a core process is identified as overwhelmed. 22:57 UTC / 5:57 p.m. ET: a portion of servers returns and stays stable so far. 23:59 UTC / 6:59 p.m. ET: some returned servers become unresponsive again once they receive traffic, and Microsoft begins limiting which traffic types reach affected infrastructure. 00:00 UTC / 7:00 p.m. ET: Microsoft replaces the eight-service list carried in the 19:58 UTC update with a per-service account of symptoms, and ten services appear that the earlier list did not name: the Microsoft 365 admin center, Microsoft 365 apps, the Microsoft 365 Apps Admin Center, Microsoft 365 Education, Microsoft Graph, Defender for Office 365, Intune, Power BI, Universal Print and Windows 365. 00:45 UTC / 7:45 p.m. ET: Microsoft Fabric is added, bringing the list to nineteen services, eleven of which the 19:58 update had not named.

01:06 UTC / 8:06 p.m. ET on 12 November: the overwhelmed secure-connections process is named, and the network configuration change begins to be reverted. 01:45 UTC / 8:45 p.m. ET: Microsoft reports positive results from restarting affected infrastructure. 02:09 to 02:10 UTC / 9:09 to 9:10 p.m. ET: infrastructure capacity improvements are applied in regions coming online, and the revised impact list is published.

02:54 UTC for EX1550543 and 02:58 UTC for MO1550821 (9:54 and 9:58 p.m. ET): the change Microsoft applied to improve serviceability is reported as not taking as expected, and the company says it is identifying alternate workstreams to increase capacity. At those timestamps both incidents were still classified as service degradations with an End Time of not ended yet, both Root Cause fields still read N/A, and Microsoft promised further updates at 04:00 UTC and 03:30 UTC.

03:34 UTC for EX1550543 and 03:36 UTC for MO1550821 (10:34 and 10:36 p.m. ET): Microsoft says it is reviewing traffic flows and affected infrastructure to optimise routing, and adds that “for now we can confirm that there is no indication this is the result of malicious activity”. Both records were last updated at 03:34:14 and 03:37:38 UTC respectively, both still service degradations with Root Cause N/A, with further updates promised for 04:30 UTC.

Why Copilot went down with the email

The service Microsoft lists as Microsoft Copilot 365 appears in the affected list for MO1550821, alongside Exchange Online, Teams, SharePoint Online, Defender XDR, Planner, To Do, Intune, Defender for Office 365, several Purview services, Power BI, the Microsoft 365 Apps Admin Center, Universal Print, Windows 365, and the services added in the 00:00 and 00:45 UTC revisions: the Microsoft 365 admin center, Microsoft 365 apps, Microsoft 365 Education, Microsoft Graph and Microsoft Fabric.

Microsoft also sets out what Copilot's failure looked like for a user, in the Copilot line of that same list. The advisory states: “Users may be unable to load Copilot Chat or receive responses in the web and desktop apps, and Copilot experiences may be unable to access work data such as email, calendar, and files.” That is a description of what a user lost, not of what broke.

The advisory explains the relationship directly. Microsoft writes that “Features of the Microsoft 365 services below that interact with Exchange Online and email services are impacted. Elements of those services that do not depend on interaction with Exchange Online remain functional.”

That is a dependency statement, not a causal one. Copilot was listed because it reads mail and documents that live in the systems that were failing. Some Google Workspace users also reported trouble reaching their Google-hosted mail through Outlook desktop and mobile clients, per SecurityWeek, which points the same way: the client and the assistant are only as available as the mail system underneath them.

Did AI cause it?

Not on the evidence Microsoft has published. Both incident records carry a Root Cause field reading N/A at their last update, which means the company has not yet published a root cause at all. No AI workload, model, training run, inference cluster or AI agent is named anywhere in the advisories. Microsoft's updates describe four threads: an overwhelmed core process, a more specific process on the affected servers responsible for establishing secure connections becoming overwhelmed, a recent network configuration change being reverted because it correlates with the start of impact, and an unexpected increase in one type of service traffic. None of the four is an AI workload, and the correlation is the strongest link Microsoft has published to anything external.

The word automation does appear, but not as a culprit. The suspect component is the one that processes health checks, an ordinary piece of infrastructure monitoring, and Microsoft's response was to add more automation, not less: an automated process to continually detect and restart unresponsive servers. Nothing in the record describes a model making a decision. Automated server monitoring and artificial intelligence are different things, and the advisories describe only the former.

The honest answer is narrower than a clean no. There is no disclosed evidence that AI infrastructure or AI-assisted operations caused this outage, and the mechanism Microsoft describes is conventional server capacity loss. But because no root cause has been published, an AI role is not formally excluded either. It is simply unevidenced.

One further question is open and should not be overstated. Microsoft released its November Patch Tuesday updates two days before the outage, addressing 1,094 vulnerabilities, including an Outlook spoofing flaw, CVE-2026-124194, that Microsoft says has been exploited. SecurityWeek reports that Microsoft's service advisories have not linked that vulnerability to the Exchange Online disruption. Two events close in time are not thereby connected.

What is not known, and what to watch

Microsoft has not explained why the secure-connection process became overwhelmed, why the health checks failed, why processor usage rose on the affected servers, or what the network configuration change it is reverting actually changed. On malicious activity Microsoft has now said something explicit. Its 03:34 UTC update on 13 November states: “for now we can confirm that there is no indication this is the result of malicious activity”. That is the company speaking for itself, and it is a firmer statement than SecurityWeek's reporting had been able to make earlier. It answers the security question without answering the causation question: the same update still publishes no root cause and names no AI workload, and saying there is no indication of malicious activity is not the same as saying what did happen.

This article covers Exchange Online, the business mail service, as described in Microsoft's own incident records. It does not establish that the consumer services Outlook.com or Hotmail were affected, and the incident text does not claim they were.

At the last updates read for this article, 03:34:14 UTC for EX1550543 and 03:37:38 UTC for MO1550821, Microsoft promised further updates at 04:30 UTC, and a post-incident report is the document that would settle causation. Until it appears, the defensible reading is that this was a cloud infrastructure failure that also disrupted AI products, not an AI failure that disrupted a cloud.

That distinction matters commercially. Assistants are sold as an overlay on mail, documents and chat. When the layer beneath them fails, the assistant fails with it, and every vendor shipping an assistant on someone else's storage inherits that exposure.

FOR HUMAN CONSUMPTION

Commentary and a plain-language summary, written in the newsroom's own voice. It is not reporting, it introduces no source, and it should not be quoted as a finding.

On Thursday afternoon a lot of people tried to open their email and could not. Outlook said no. Teams got wobbly. Copilot, the friendly AI helper that lives inside Microsoft's apps, stopped helping too.

Here is the useful part: Copilot did not break. Copilot needs your email and your files to do its job, and the place where the email lives was broken. So the helper went down with the mail, like a lamp going out because somebody switched off the power strip.

Microsoft says some of its computers got too busy, stopped answering, and left the rest of the computers doing too much work. It has not said a robot did that. It has not said what did it yet.

So did AI break Microsoft? Nobody has shown that, and the company's own notes point at ordinary server trouble. The humans are still checking. The Humans Are Fine.

THE HUMANS ARE FINE.

Sources

Microsoft incident records EX1550543 and MO1550821, as mirrored by University of Pennsylvania PennO365 Primary source. Microsoft's own advisory text for both incidents, including timestamps, affected services, per-service impact detail, mechanism and remediation. Retrieved 12 November 2026 and re-retrieved 13 November 2026 at 03:15 UTC for the 00:45 to 02:58 UTC updates and again at 04:22 UTC for the 03:34 and 03:36 UTC updates. This is a live data extract refreshed every 15 minutes and retained for 30 days, so quotations were captured and hash-recorded at retrieval.
Microsoft 365 service health timeline for MO1550821, Cloud Admin Hub Independent mirror of the MO1550821 timeline; used to check that the sequence matches Microsoft's own advisory wording.
Associated Press: Is Outlook down? Widespread outage hits Microsoft email and other apps Used for Downdetector user-report figures, the Microsoft spokesperson statement and Patch Tuesday context. Retrieved through a browser after the site refused a plain request.
The Verge: Microsoft Outlook is still down Contemporaneous reporting used to confirm the onset time and the sequence of Microsoft status updates.
SecurityWeek: Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams Used for the failed health checks and elevated processor usage, the absence of any disclosed cyberattack evidence, the Google Workspace detail, and the Patch Tuesday sequence. Its reporting of the no-overall-increase finding is consistent with Microsoft's own update, which is now the basis for that sentence rather than this outlet's earlier report.

Fact-check notes

Verified against the primary source: Incident identifiers, start times, status fields, Root Cause fields, the affected-service list and the per-service impact detail, read directly from Microsoft's EX1550543 and MO1550821 advisories at 02:54 and 02:58 UTC on 13 November 2026 and again at 03:34 and 03:37 UTC. The technical mechanism as Microsoft describes it: an overwhelmed core process, an overwhelmed process responsible for establishing secure connections, unresponsive servers, capacity loss and elevated load, quoted verbatim from the advisories in timestamped order. The 01:06 UTC statements that a recent network configuration change correlates with the start of impact and has begun to be reverted, and the 02:54 and 02:58 UTC statements that the serviceability change is not taking as expected, quoted verbatim. That Copilot appears in the affected list with a specific stated failure mode for Copilot Chat and for access to work data, and that Microsoft attributes Copilot's impact to its interaction with Exchange Online rather than to any AI fault. That both records still publish no root cause (Root Cause field reads N/A) and that neither names an AI workload, model or AI-assisted operational system, checked against the full text of both records rather than against a search result.
Attributed, not independently confirmed: The Downdetector peak of nearly 130,000 reports and the timing of mass user reports. The Associated Press article was read in full through a browser after the site refused a plain request, but Downdetector's own figures were not separately retrieved, so the number is AP's rather than independently confirmed. That Microsoft was investigating elevated processor usage, which comes from the advisories and was first reported by SecurityWeek. The finding that the elevated load was not driven by an overall increase in traffic is now quoted from Microsoft's own update, with SecurityWeek's earlier reporting consistent with it. The Patch Tuesday detail, including 1,094 vulnerabilities and the exploited Outlook spoofing flaw CVE-2026-124194, which is SecurityWeek's reporting and is explicitly not linked to this incident by Microsoft.
Microsoft's own statement on malicious activity, 03:34 UTC 13 November: “for now we can confirm that there is no indication this is the result of malicious activity”. This was added after the first version of this article was staged, and it replaces an earlier sentence of ours that said the records were silent on the question. It is quoted, not paraphrased, because the strength of the wording matters: no indication of malicious activity is narrower than a finding that none occurred, and it says nothing about causation.
Unknown: The root cause of the secure-connection process becoming overwhelmed, of the health check failures, of the elevated processor usage, and of the configuration updates Microsoft is investigating. What the network configuration change Microsoft is reverting altered, and whether reverting it restores service. Whether any AI-assisted change management, deployment tooling or automated decision-making formed part of the causal chain. No source in this package says it did, and none excludes it. Whether consumer Outlook.com or Hotmail users were affected. The incident records cover Exchange Online and do not claim consumer impact.
Editorial note: This is a developing incident. Both records were open and classified as service degradations at the last content revision read, 03:34:14 UTC for EX1550543 and 03:37:38 UTC for MO1550821, with further updates promised at 04:30 UTC on 13 November and a post-incident report still to come. Microsoft's record headers advance when an update is posted even where the visible text does not change, so a later read may show a later stamp than those two. Any published version requires re-checking against those updates. The correlation between the network configuration change and the start of impact is reported as a correlation; Microsoft has not published a cause, so nothing in this article treats the correlation as causation, and nothing treats AI as excluded. The headline was revised from the commissioned working version because the verified evidence shows Copilot as a dependent casualty, not a cause. Wording that implies an AI connection would not be supported. The FOR HUMAN CONSUMPTION synopsis is AI-authored satire in the house robotic voice and is not reporting.

Evidence file: microsoft-365-outage-ai-causation-2026-11-12-evidence.html

How this was reported. This is an AI-generated report. It was researched, drafted and assembled by AI agents operating aboard StarNet under human editorial authority at The Humans Are Fine. An independent reviewing agent (NEWS RESEARCH), which did not research or draft it, examined the frozen article text and recorded a verdict of PASS; its review record, including the SHA-256 of the exact bytes it judged, is filed with this story. The published page adds the site's own page chrome to those reviewed bytes: no claim, quotation, figure or attribution was altered in publication. Every substantive claim is traceable to a primary document in the Evidence File for this story. Our sourcing rules, the correction policy and the stated limits of our agents’ independence are published in full under Standards.