Microsoft 365 outage, Nov 12: what failed, what to do

On Thursday, November 12, 2026, Microsoft 365 went down for a large share of its business customers. Microsoft is tracking it in the admin center as MO1550821, with the Exchange Online part as EX1550543, according to BleepingComputer, SecurityWeek and TechRepublic. BleepingComputer reports that Microsoft gave the start time as 1:26 PM ET (10:26 AM PT). According to Reuters, as cited by TechRepublic, Downdetector recorded more than 130,000 Outlook problem reports around 1:27 p.m. ET.

Where it stands on November 13

The overnight hours were rough. At 03:07 UTC Microsoft said a change it had applied was "not taking as expected," and at 04:22 UTC that its traffic adjustments "aren't resulting in sustained recovery." The turn came at 07:29 UTC, when Microsoft reported "positive results for server stability after applying an upstream authentication/routing configuration component patch to a portion of our infrastructure." Recovery then rolled out region by region, and the later posts moved from progress reports to cause and caveats:

• 11:04 UTC (3:04 AM PT): recovery actions completed across parts of the affected infrastructure in Asia Pacific, with improvements in "mailbox access and delayed email processing."
• 12:00 UTC (4:00 AM PT): "encouraging recovery progress in Europe," and North America "also improving."
• 12:58 UTC (4:58 AM PT): "broader improvements now observed in North America."
• 14:00 UTC (6:00 AM PT): email queues "significantly reduced and approaching normal levels," with Microsoft "restoring the remaining affected infrastructure while investigating residual service issues."
• 14:56 UTC (6:56 AM PT): "sustained improvements in service availability," with efforts "increasingly focused on resolving the remaining issues and restoring consistent service for all affected users."
• 16:07 UTC (8:07 AM PT): "At this time, we have no evidence of malicious activity associated with this incident." Microsoft says it will share "a full Post-Incident Report with root cause and defense-in-depth actions after mitigation is complete."
• 17:57 UTC (9:57 AM PT): Microsoft apologized ("We are deeply sorry for the disruption this incident has caused you and your business") and said, "We are seeing broad recovery and stability across our services." It also gave a cause (see below) and said it would "continue to restore service to remaining customers and regions."
• 20:02 UTC (12:02 PM PT): "[W]e're still draining queued messages and rebalancing traffic, so customers may see improved sign-in/access while delivery and processing continue to catch up. We do not have an ETA for full recovery yet. Service access can recover before mail flow fully normalizes."

The 20:02 UTC post is more cautious than the 17:57 UTC "broad recovery" post. We are quoting both as Microsoft wrote them, and we are not reconciling them. Which one matches your tenant is a question for your own Service health page.

One change matters for anyone worried about lost mail. From 09:14 UTC, Microsoft says it is "extending the email timeout window to 48 hours to help protect delayed messages while service recovery continues." That is Microsoft holding on to queued mail longer than usual, and it is the clearest sign so far that a long delay should not turn into a bounce on Microsoft's side.

If Outlook works for your users now, that fits Microsoft's account. If some still can't connect, or mail from yesterday afternoon is only now arriving, that fits too, because Microsoft says access can recover before mail flow does. Microsoft has not declared the incident resolved.

What Microsoft says is broken

Microsoft's own summary is 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." So Exchange Online is at the center, and a lot of Microsoft 365 turns out to lean on it.

For Exchange itself, Microsoft says users "may be unable to access their mailbox using Outlook on the web, Outlook desktop (MAPI), Exchange ActiveSync (EAS), or REST-based connections, and email delivery may be delayed." That covers Outlook in the browser, Outlook on the desktop, and most phone mail apps.

Microsoft's impacted list grew through the incident. As of its 20:02 UTC November 13 update it also names:

• Teams: "Most of the core functionality including joining calls, meetings, group chats, and channel messages are not impacted." What fails is anything that depends on Exchange Online: calendar scheduling, invites and meeting edits, creating Live or Virtual events, and creating or deleting private or shared channels.
• SharePoint Online: features that depend on Exchange may be impacted, and some users may have trouble sharing files with people outside the organization, but "accessing files stored directly in SharePoint Online remains functional."
• Microsoft 365 Copilot: may not load or answer, and may be unable to reach work data "such as email, calendar, and files."
• Microsoft Graph: "API requests that access Exchange Online data, such as mail, calendar, and contacts, may time out."
• Security and compliance: Defender XDR, Defender for Office 365, and Purview (details in the next section).
• Also listed: the Microsoft 365 admin center, the Microsoft 365 Apps admin center, Intune (device enrollment, check-in and compliance "may have been intermittently impacted"), Planner, To Do, sign-in to the Power Apps and Field Service mobile apps, Power BI and Fabric exports of sensitivity-labeled reports, Universal Print, Microsoft 365 Education features, and Windows 365 Cloud PCs that use Purview Customer Key.

Consumer services are affected too. Microsoft's consumer status feed lists Outlook.com, OneDrive, OneNote, To Do, Teams, and Microsoft 365 for the web.

Your security tools are on the list

This is the part we would want a client to read first. Three security and compliance services are on Microsoft's impacted list:

• Defender for Office 365: through Microsoft's 01:06 UTC November 13 update, "Safe Links may be unable to verify URLs, which may impact users clicking links in Outlook and Teams." By 14:00 UTC that line was gone, replaced by "delays or failures in policy evaluation and governance action enforcement" for experiences that rely on Purview DLP and Information Protection signals.
• Defender XDR: "Users may be unable to load Microsoft Defender portal pages or solution tabs."
• Purview: the list grew overnight. It now includes Data Loss Prevention "across Microsoft 365 services," auto-labeling, Information Protection label policies, Communication Compliance, role-based access control and Data Classification, and says "Audit searches, protected content creation, eDiscovery tasks such as search and export ... may also be impacted."

In plain terms, for at least the first part of the outage the link-checking that normally sits between your staff and a bad URL may not have been working. The portal your team would use to investigate may not load, data loss prevention may not be enforcing, and audit searches you would run afterward may fail for now. None of that means you are under attack. It does mean you are watching with less than usual for as long as this lasts. Defender XDR was on Microsoft's impacted list in the August incident too.

It reaches beyond Microsoft

Anything that reads mail or calendars through Microsoft Graph or connects to a mailbox is affected too. Several vendors posted their own incidents within hours. ConnectWise said the Microsoft incident "can impact Email Connector and Calendar Sync" in its PSA. Zoom reported "Service Degradation Affecting Microsoft Integrations due to an underlying vendor issue."

AI assistants that connect to Microsoft 365 were hit too. Anthropic's status page opened "Elevated errors affecting the Microsoft 365 connector" at 17:52 UTC on November 12 (9:52 AM PT). At 22:23 UTC it said, "This issue is caused by a Microsoft 365 service incident," and that mail, calendar and search tools in the connector were "still failing for most requests." Claude for Outlook was also affected. In its 15:40 UTC November 13 update the incident was still in "monitoring": "Some SharePoint search requests are still returning errors. Microsoft's incident remains open, so errors may return."

OpenAI's status page opened an incident with the same title, "Elevated errors affecting the Microsoft 365 connector," on November 12 at 10:29 AM PT (18:29 UTC): "new connections may be broken and tools are not working as expected." It was still monitoring as of 08:20 AM PT on November 13. OpenAI's page states no cause. It happened the same day as the Microsoft incident, and we are not saying one caused the other.

The point for you: an AI assistant connected to your mailbox fails when the mailbox does, so list those tools in your incident runbook next to the PSA and the CRM.

Your ticketing system, CRM, scheduling tools, and any automation that reads a shared mailbox are in the same position. If something "unrelated" is misbehaving today, check whether it touches Exchange first.

This is the second large Microsoft infrastructure incident in about six weeks. Our post on the September 30 Azure gateway outage covers the earlier one.

What Microsoft says caused it, so far

Microsoft gave a cause at 17:57 UTC on November 13 (9:57 AM PT), and repeated it on its consumer status page at 18:57 UTC. In its words: "This was a technical issue not related to cyber or AI / agents. The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change." It added that it had "addressed the underlying issue" and, "given the scale of demand," restored services gradually, "validating stability at each stage."

That is Microsoft's account so far, in a status post. The promised post-incident report "with root cause and defense-in-depth actions" has not been published yet. Treat the status text as a working account until the report arrives.

The explanations Microsoft gave during the incident are the history. At 19:30 UTC on November 12 it said "the elevated load isn't driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure." It also said it had "paused all deployments and configuration changes." By 01:06 UTC on November 13, it said that "a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests," and that it had "begun reverting a recent network configuration change that correlates with the start of impact."

At 04:57 UTC it added that it had "observed a surge in outbound call volume from our routing services to our backend servers," and that machines "stuck in a bad state" were preventing its network change from syncing. The fix that moved things, at 07:29 UTC, was "an upstream authentication/routing configuration component patch." Microsoft has not said how these earlier descriptions fit with the 17:57 UTC summary. On the question everyone asks first, Microsoft's words since 10:01 UTC November 13 were: "At this time, we have no evidence of malicious activity associated with this incident." The 17:57 UTC post goes further and says it was not related to cyber.

What to do now

• Tell people what still works. According to Microsoft, Teams chat and online meetings "remain largely functional," and files stored directly in SharePoint are reachable. Move urgent coordination there and keep phone numbers handy for anything that can't wait.
• Don't let users mass-resend email. Microsoft says delivery "may be delayed," and it has extended its email timeout window to 48 hours to protect queued mail. Yesterday afternoon's messages arriving late is recovery working, not a new problem. Resending everything mostly creates duplicates.
• Hold off on reinstalls and profile rebuilds. If Outlook can't connect, deleting the profile or reinstalling Office won't help while the service is down. It just adds work later.
• Write down your own timeline now. Record when your first user reported a problem, which services failed for you, and when they came back. In our review of the August incident, Service Health posts sometimes appeared a day or more after Microsoft's own stated start. Your record is evidence. Microsoft's history view may not be.
• Record the incident IDs: MO1550821 and EX1550543. Check them in your own admin center under Service health, because that is the record that applies to your tenant.

After it is resolved

• Check for real bounces. Once mail flows again, look for non-delivery reports and for messages that sat in queues. Those are the failures. Everything else was a delay. Ask partners and customers who emailed you on November 12 to tell you if they got a bounce, because a bounce generated by their mail server lands in their inbox, not yours.
• Decide on a service credit by December 31. Microsoft's SLA requires a claim by the end of the calendar month after the incident month. For a November 12 incident, that is December 31, 2026. Whether a credit applies depends on your tenant's measured uptime, and a credit is a percentage of one month's fee for the service, not compensation for lost business. Our August outage post walks through the tiers and who you file with.
• List what broke that you didn't know depended on Exchange. Universal Print, Intune, Copilot, Planner, and your PSA's email connector are all on today's list. Each one you didn't expect is a gap in your continuity plan.
• Read the post-incident report when it lands. For August, Microsoft's final report changed both the root cause and the scope compared with what it said during the incident. Expect the same here.

For the bigger question of what Microsoft protects and what stays your job, see Microsoft 365 backup: what Microsoft covers, and what you do.

Where we fit

We can't fix Microsoft's servers, and no one outside Microsoft can. What we do is the work around them: map which of your systems quietly depend on Exchange Online, make sure Service Health alerts reach a person, write the runbook for the next outage, and check whether you're owed a credit. Vendor-neutral and labor-only.

Sources

• Microsoft 365 status page, status.cloud.microsoft (Microsoft's public posts for this incident, captured 18:59 UTC November 12 through 20:02 UTC November 13, 2026)
• Anthropic status: Elevated errors affecting the Microsoft 365 connector
• OpenAI status: Elevated errors affecting the Microsoft 365 connector
• BleepingComputer: Massive Microsoft 365 outage disrupts Outlook, Teams, Copilot worldwide
• SecurityWeek: Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams
• TechRepublic: Microsoft Outlook Down: Over 130,000 Outage Reports

The 30-second version

Microsoft 365 incident MO1550821 (Exchange Online: EX1550543) began around 10:26 AM PT on November 12, 2026, ran through the night, and was still open at 12:02 PM PT on November 13, when Microsoft said it had no ETA for full recovery and that service access can recover before mail flow normalizes. Microsoft has extended its email timeout to 48 hours. Its account so far: a technical issue, "not related to cyber or AI / agents," introduced during an earlier network capacity upgrade. Its post-incident report is still to come. Exchange Online is at the center, and anything that leans on it is affected, including Teams calendars, Copilot, Graph-connected apps, AI assistants connected to the mailbox, and Microsoft's own security tools: Safe Links, the Defender portal, and Purview DLP. Teams chat, meetings, and SharePoint files mostly still work. Tell staff to be careful with links and not to route work data through personal accounts. Write down your own timeline, and if you want a credit, file by December 31. If you'd like a senior engineer to map what your environment depends on before the next one, the project intake form takes about three minutes.

Pro IT NW helps regulated mid-market organizations run Microsoft 365, Exchange, and hybrid environments. Vendor-neutral, labor-only. This post reflects Microsoft's public status posts as of 20:02 UTC, November 13, 2026 (12:02 PM PT). The incident was still open, Microsoft had given no ETA for full recovery, and it had not published its Post-Incident Report.