Outlook Went Dark at Lunch. It Wasn’t a Hack.

Lunch hour on the East Coast, and Outlook simply stopped. No new mail, no calendar, no connection — first in the Americas, then, by Microsoft’s own admission, for users in any region. By mid-afternoon on Thursday, November 12, the failure had spread across Microsoft 365: Teams, SharePoint Online, Copilot, Defender XDR, even parts of the admin center admins use to check what is broken. Downdetector logged almost 130,000 Outlook reports at the peak. And the first question in every IT channel was the obvious one: was this a hack?

On the evidence Microsoft has published: no. This was Microsoft’s own infrastructure failing — a large number of its servers dropping out of service at once, and the rest buckling under the load that landed on them. As of Microsoft’s 5:11 PM ET update, the incident was still open, recovery was under way, and there was no estimate for full restoration.

What happened, hour by hour

The day actually started with a smaller fire. At 9:45 AM ET, a Teams incident tracked as TM1550488 hit users in North and South America — messages delayed or failing, chats refusing to load. Microsoft blamed resource contention inside its infrastructure and closed it by 10:53 AM. It has not said the two incidents are related.

The main event opened at 11:17 AM ET as EX1550543, an Exchange Online incident: users unable to connect to their mailboxes through any method. Microsoft’s first public post came at 12:54 PM. At 1:26 PM, the incident widened into MO1550821, a full Microsoft 365 service degradation covering Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR, Planner, To Do, Intune, Defender for Office 365, several Purview services, part of Power BI, and parts of the Microsoft 365 admin center. User reports also hit OneDrive and the Microsoft Store, and Downdetector’s Outlook counter peaked at roughly 130,000 reports around 1:20 PM, just before Microsoft widened the incident.

So, was it a cyberattack?

Nothing Microsoft has published points to one — and the company has been unusually specific about what did happen. Its first theory, elevated load across multiple regions, was revised within hours: “We determined the elevated load isn’t driven by an increase in traffic, but by a number of servers being unexpectedly unavailable, straining the remaining infrastructure.” In plain terms, a large number of Microsoft’s own servers failed their automated health checks and stopped responding; everyone’s connections shifted onto the machines still standing, which then struggled under the weight. Later updates added that a core process on the affected servers becomes overwhelmed, which is what makes them stop responding.

One warning about the screenshots flying around: Downdetector reports for Azure spiked on Thursday too, and plenty of posts declared Azure down. Azure’s official status page showed no issues. User reports measure frustration, not service health — the same crowd that cannot reach Outlook will happily report every Microsoft product on the page. Trust the status page, not the spike.

Microsoft’s recovery work, meanwhile, is the standard big-outage playbook, executed in public: redistributing connection traffic across its worldwide infrastructure, restarting and validating the failed servers, and pausing all deployments and configuration changes while it reviews recent changes for a correlation. A different health-check method has already returned some servers to service, an automated recovery process is being prepared to keep restarting unresponsive machines, and the team is assessing whether reverting a small number of recent configuration updates would speed things up. At 5:11 PM ET, Microsoft conceded its actions “have not provided the anticipated relief” — but report volumes have been falling through the afternoon, and Copilot is back for most users.

What admins should do right now

Track the right records. Follow EX1550543 and MO1550821 in the Microsoft 365 admin center under Service Health. If the admin center itself will not load — parts of it are on the affected list — Microsoft posts the same updates publicly at status.cloud.microsoft and on its @MSFT365Status account on X.

Communicate off-platform. Tell your users early, through channels that do not depend on Microsoft 365, and say plainly that it is a Microsoft-side outage — not their password, not their laptop, not something they clicked. Do not have users reset passwords or re-enroll devices to “fix” this. With Intune on the affected list, expect sign-in and Company Portal oddities that are really the outage wearing a disguise; our guide to telling real Company Portal login failures from weather like this will help once services are back and something still looks wrong.

Expect a messy recovery. When Exchange Online comes back, queued mail arrives in floods and some of it bounces or lands out of order — if your inbox is quiet afterwards, that is a different problem with its own checklist, covered in our post on emails bouncing while everything looks fine. Warn users now about the other guaranteed follow-up: fake “your mailbox is being restored — sign in to reactivate” phishing that rides every major outage. The outage is real; the reactivation link will not be.

Change nothing. Microsoft has paused its own deployments mid-incident. Match that discipline: no tenant changes, no policy experiments, until the incidents close.

This is a developing story. This post reflects Microsoft’s status as of about 6:00 PM ET on November 12, 2026, with the next update due by 6:30 PM ET. Sources: BleepingComputer’s outage coverage and Microsoft’s @MSFT365Status and service status statements.