Microsoft 365 outage, 12 November 2026: what happened and what admins can do

All times below are UK time, which is the same as UTC in November.

What happened

There were two separate incidents on the same day:

• TM1550488, Teams (resolved). From 14:45 to 15:53, users in the Americas had delayed and failed chat messages and delays in presence. Microsoft's preliminary cause is "resource contention" in the underlying infrastructure. It has promised a preliminary post-incident report within two business days and a final one within five.
• EX1550543, Exchange Online, and MO1550821, Microsoft 365 (still open at the time of writing). This is the big one. It started at 16:17 with people unable to open their mailboxes. At 18:26 Microsoft opened a second incident for every service that depends on Exchange Online. The full list is below.

Outlook problem reports on Downdetector peaked at about 130,000, around 18:00. Microsoft first described the problem as affecting the Americas, then said it "may affect Microsoft 365 service connectivity for users in any region."

What's affected

Microsoft's admin centre post for MO1550821 says that features which "interact with Exchange Online and email services are impacted", while parts of those services that don't depend on Exchange Online keep working. As of 09:10 on 13 November, it listed:

• Exchange Online: no mailbox access through Outlook on the web, desktop Outlook, mobile mail or REST, and "email delivery may be delayed".
• Teams: "Most of the core functionality including joining calls, meetings, group chats, and channel messages are not impacted." Calendar scheduling, invites and meeting edits, creating Live or Virtual events, and creating or deleting private or shared channels may fail.
• SharePoint Online: features that depend on Exchange Online. Files stored in SharePoint can still be opened.
• Microsoft 365 Copilot: Copilot Chat may not load or answer, and may not reach email, calendar or files.
• Defender for Office 365: users clicking links rewritten by Safe Links will get "a failure to navigate, as Safe Links fails to process it." Releasing items from quarantine may also fail.
• Defender XDR and Purview: portal pages may not load. Purview's DLP, auto-labelling, communication compliance and data classification are affected.
• Windows 365: tenants using Microsoft Purview Customer Key for Cloud PCs may have users who can't connect.
• Microsoft Graph: requests for mail, calendar and contacts may time out, so scripts and integrations that read mailboxes will fail too.
• Microsoft Fabric: exporting reports with sensitivity labels to PDF or PowerPoint, updating labelled items, or opening a labelled .pbix in Power BI Desktop may fail. Microsoft's workaround is to remove the label from the item, if your data protection policies allow it.
• Power Apps: users "may be intermittently unable to sign-in to the Power Apps or Field Service mobile apps." Microsoft says the web versions may work instead, and people already signed in can "potentially avoid impact by not signing out, clearing app data, or reinstalling while the issue is ongoing."
• Also listed: Planner, To Do, Intune, Power BI (exporting labelled reports to PDF), the Microsoft 365 Apps admin center, Universal Print, some Microsoft 365 admin center pages, recent files in the Microsoft 365 apps, and Microsoft 365 Education features.

Two things are easy to miss in that list. Mail that's delayed isn't lost, so it should arrive once service returns; at 09:10 Microsoft said it is extending the email timeout window to 48 hours to protect delayed messages. And with Safe Links affected, users may hit errors on links in emails and Teams that have nothing to do with the link itself.

What Microsoft has said

Microsoft has posted updates in the admin centre and on its Microsoft 365 Status account. In order:

• 16:20: investigating a potential issue with mailbox access.
• 18:19: a part of its infrastructure was under "elevated load across multiple regions". Outlook on the web, desktop Outlook (MAPI), mobile mail (EAS) and the REST API were all affected. Microsoft started restarting servers and looking at redirecting traffic.
• 18:29 to 18:57: it moved some US traffic off the affected infrastructure, then redistributed Outlook connections worldwide, warning that this could add latency.
• About 19:06: it paused all deployments and configuration changes while it reviewed recent changes.
• About 19:18: the extra load wasn't coming from more traffic. "We determined the elevated load isn't driven by an increase in traffic". Instead, a number of servers had become unexpectedly unavailable, which pushed their work onto the servers that were left.
• 19:43: the affected servers were failing automated health checks, so they were being taken out of service.
• About 19:57: "We've not identified any recent change correlated with the start of impact; however, our investigation indicates the failed health checks may originate from a specific component that's responsible for processing server health." Microsoft started testing a way to bypass that component on some servers.
• 20:38: many of the affected servers became unresponsive while Microsoft was validating the change, so it restarted them with the change applied.
• 20:56: "We've validated an alternative service health check method, which allowed a subset of affected servers to successfully return to service." Microsoft said it was applying this more broadly, and building an automated process to restart servers that stop responding.
• 21:31: Microsoft was restarting and validating servers, and "assessing whether reverting a small number of recent configuration updates we identified could help accelerate recovery."
• 22:00: "our actions taken thus far have not provided the anticipated relief." Microsoft said: "We found a core process on affected servers is becoming overwhelmed, causing capacity loss." It began isolating and restarting part of the infrastructure.
• 22:57: the servers being returned "remain stable so far". Microsoft was shifting traffic to alternate routes, "observing limited recovery", and had put protective traffic management in place in one location.
• 00:00 on 13 November: the returned servers "can become unresponsive again once they begin receiving traffic." Microsoft started limiting which types of traffic reach the affected infrastructure in some locations, to find out whether "a particular type of request is contributing to the impact", and began rebuilding some servers "using a previous software configuration".
• Overnight (before 01:50): Microsoft said "a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests." It was validating a configuration change on some servers before applying it everywhere, and had "begun reverting a recent network configuration change that correlates with the start of impact." The traffic limits were in effect in specific locations.
• 01:50: "We're seeing positive results with our efforts to restart affected infrastructure." Microsoft said it would expand the fix "as we confirm stability with the changes applied."
• 02:14: "We're applying infrastructure capacity improvements where possible in an effort to help support traffic in regions coming online." Microsoft said it was monitoring the results to improve service health "across all affected regions."
• 03:07: Microsoft "confirmed that change is not taking as expected" and is "identifying alternate workstreams that can be applied to increase capacity in the face of sustained traffic management imbalances."
• 03:37: Microsoft said it was "reviewing traffic flows and affected infrastructure to identify opportunities to optimize routing", and "verifying the reasons for service failures so we can develop specific actions to improve stability."
• 04:11: "We can confirm that there is no indication this is the result of malicious activity." Microsoft said it would "continue to apply learnings towards remediation actions."
• 04:22: "We're observing partial recovery across regions in which we've applied these adjustments; however, these actions aren't resulting in sustained recovery." Microsoft said it was "adjusting traffic protocols, redistributing traffic, and applying strategic traffic blocking measures", and "reviewing what additional actions we can take to improve overall infrastructure stability."
• 04:57: Microsoft said "we've observed a surge in outbound call volume from our routing services to our backend servers", which "occurs when the backend servers outbound service cannot properly route to the backend machines." It is "scaling up virtual machines to increase capacity and reduce load" and trying to force sync its recent network change, but "we are encountering issues with the machines being stuck in a bad state, preventing our changes from syncing as expected."
• 05:46: "We're continuing to pursue multiple workstreams to pinpoint the underlying cause of the traffic influx and advance the recoverability of the backend servers." Microsoft said it is "taking a measured approach to identify and repair affected infrastructure" and is "tracking the results of this approach to verify the servers are showing the anticipated recovery and performance intended." It repeated that it is "not aware of any malicious activity" and promised a Post-Incident Report once mitigated.
• 06:17: "As part of our ongoing efforts to advance the recoverability of our frontend servers, we're evaluating traffic controls that can be applied to increase capacity and stability." Microsoft said this "includes traffic optimization actions such as traffic throttling, protocol adjustments, and failover routing intended to improve stability in active regions", and that it is expanding internal testing "to improve traffic monitoring and issue detection capabilities." It again said it is "not aware of any malicious activity" and that the next update is due by 07:00.
• 06:57: Microsoft said it is reviewing server performance and "confirming that developed patches have been applied and working as intended after infrastructure reboots are completed. At this point, we have observed marginal success." It is also "taking action to expand capacity through the utilization of Virtual Machines." It again said it is "not aware of any malicious activity" and that the next update is due by 07:30. Its list of affected services now also includes Power Apps.
• 07:29: "We're seeing positive results for server stability after applying an upstream authentication/routing configuration component patch to a portion of our infrastructure." Microsoft said "We'll continue to monitor its progress and are working to expand it to servers supporting active regions coming online." It again said it is "not aware of any malicious activity" and that the next update is due by 08:30. The incident is still listed as "Service degradation".
• 09:10: "Recovery efforts are ongoing across impacted infrastructure. We are seeing early signs of stabilization, but service capacity has not yet returned to normal levels and health remains variable as traffic is carefully reintroduced." Microsoft said engineers "are cycling affected infrastructure through traffic drain, restart, remediation, and staged return-to-service" and are "evaluating additional mitigation options to improve recovery speed and consistency." It is "extending the email timeout window to 48 hours to help protect delayed messages", is "not aware of any malicious activity causing this incident", and "will share a full Post-Incident Report with root cause and defense-in-depth actions after recovery is complete." Next update due by 10:00. The incident is still listed as "Service degradation".

What it means

Microsoft's early updates pointed at the system that decides which servers are healthy:

1. A component that processes server health checks started failing servers that may have been fine.
2. Those servers were taken out of service.
3. The servers that were left took on their work and became overloaded.
4. Users couldn't connect, through any client.

The overnight updates changed the picture. Microsoft now says the problem is a process that sets up secure connections on each server. It gets overwhelmed, and the server stops handling requests. So the health checks were right to fail those servers: the servers really had stopped working.

The bigger change is about the cause. At 19:57 Microsoft said it had "not identified any recent change correlated with the start of impact". Overnight, it said it had begun reverting "a recent network configuration change that correlates with the start of impact." That's not a confirmed root cause yet, but it's the clearest sign so far of what triggered this. Wait for the post-incident report before drawing conclusions.

At 04:11 on 13 November, Microsoft confirmed "there is no indication this is the result of malicious activity."

Can you fix an outage like this?

No. When the problem is inside Microsoft's datacentres, nothing you change in your tenant will bring mail back. Switching clients doesn't help much either, because Microsoft listed Outlook on the web, desktop Outlook, mobile mail and the REST API as affected.

What you can control is how fast you find out, what your users hear, and what you have afterwards.

During the outage

1. Check it's Microsoft, not you. Look in the Microsoft 365 admin centre under Health > Service health. If you can't sign in, use Microsoft's public status page at status.cloud.microsoft and the @MSFT365Status account. Your service desk can see Service health too: Microsoft says the Service Support admin and Helpdesk admin roles can view it.
2. Follow the incident ID, not the news. EX1550543 and MO1550821 are where Microsoft posts its updates first, and they show whether your tenant is affected.
3. Tell users once, early, and outside Microsoft 365. If Outlook and Teams are both down, an email or Teams post won't reach anyone. Use SMS, an intranet that isn't hosted on SharePoint, or whatever channel you'd use in any other emergency.
4. Stop people "fixing" it. Ask users not to reinstall Office, delete their Outlook profile or reset passwords. None of that helps with an outage, and it makes the recovery noisier.
5. Freeze your own changes. Microsoft paused its deployments. Do the same with yours, so that when things come back you know any new problem is theirs.

You can also check an incident from a script with the Microsoft Graph service communications API. It needs the ServiceHealth.Read.All permission, and with delegated access the signed-in user also needs an admin role:

1
2Connect-MgGraph -Scopes ServiceHealth.Read.All
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/issues/EX1550543"

After it's fixed

• Get the post-incident report. When Microsoft publishes it, the incident's status changes to "Post-incident report published", and the report includes the root cause and what Microsoft will do to stop it happening again. You can also download it with Graph: GET /admin/serviceAnnouncement/issues/EX1550543/incidentReport.
• Save it. Service health only shows issue history for the last 30 days. If you need the report for a service review, an SLA claim or your own incident record, keep a copy.
• Write down what it cost you. Which teams were affected, for how long, and what workarounds people used. That's what you'll need if you ever make the case for a backup channel.

Before the next one

• Turn on email alerts. In Service health, select Customize > Email, then Send me email notifications about service health. Each admin can add up to two addresses and pick the services they care about. Send at least one to an address that isn't in Microsoft 365, or you won't get the alert when you need it.
• Install the Microsoft 365 Admin app. It shows Service health on your phone and sends push notifications.
• Agree an out-of-band channel now. Decide how you'll reach staff when Outlook and Teams are both down, and who sends the message.
• Pull service health into your own monitoring. The same Graph API lets you raise an alert in your ticketing or monitoring tool, so your service desk sees Microsoft incidents next to everything else.