Microsoft 365 Outage, November 2026: What Went Wrong, How Microsoft Can Fix It, and What to Do Now

Microsoft 365 has been down or unstable for much of the world since Thursday afternoon UK time. Outlook, Exchange OnlineThe KBY LexiconExchange OnlineExchange Online is Microsoft's cloud-hosted email, calendar and contacts service, delivered through Microsoft 365 as hosted mailbox infrastructure. Read Full Context , Teams, SharePoint, OneDrive and Copilot have all been affected. Microsoft says the cause is not a cyberattack. Servers in its Exchange Online infrastructure went unexpectedly offline, and a process that sets up secure connections on the remaining servers became overloaded, so they stopped handling requests too. Its first fixes did not hold, because servers it brought back fell over again as soon as traffic reached them. Overnight, Microsoft began reversing a recent network configuration change that it says correlates with the start of the outage. If your users cannot get to mail or Teams, the fault is almost certainly not in your tenant, your network or their devices. Stop troubleshooting locally, tell people what is happening, and switch to the fallbacks below.

This article covers what we know, what Microsoft has said, where the incident stands, our view of what has gone wrong and how Microsoft can fix it, and what IT teams should do today and after recovery.

#Where things stand

As of Friday 13 November, Microsoft had not declared the incident resolved. Its latest updates describe limited recovery, with no time given for full restoration. Treat any service that is working now as fragile until Microsoft closes the incident in the Microsoft 365The KBY LexiconMicrosoft 365Microsoft 365 defined at plain and technical depth, with architecture, operational relevance, an example and a common misunderstanding for practitioners. Read Full Context admin centre.

• What is affected: Exchange Online is at the centre: Outlook on the web, the desktop and mobile apps, and Outlook.com. Services that depend on Exchange are hit too, including Teams calendars and scheduling, SharePoint OnlineThe KBY LexiconSharePoint OnlineSharePoint Online is Microsoft's cloud-based collaboration and document management service, delivered as part of Microsoft 365. Read Full Context , Microsoft 365 Copilot, Planner and To Do. Reports also name Intune, Purview, Defender XDR and Defender for Office 365, where Safe Links may be unable to check URLs. Teams chat and meetings have mostly kept working.
• Where: Worldwide. Reports came first from North America, then from the UK, Europe, Asia-Pacific and Australia as each region started its working day.
• Incident IDs: Microsoft is tracking the problem in the admin centre’s Service health page as EX1550543 (Exchange Online) and MO1550821 (the wider Microsoft 365 impact). Those are the records to follow and to quote in any support case or service credit claim.
• Cyberattack: Microsoft says it has no indication of malicious or cyber activity. Charles Lamanna, a Microsoft executive vice president, repeated that publicly.
• Azure: some early reports listed Azure as down, but Microsoft’s incident does not include it and the Azure status page stayed clear. This is a Microsoft 365 outage.

#Timeline

Times are UK time (GMT, the same as UTC in November). Microsoft’s US posts use Eastern time, five hours behind.

• Thursday 12 November, about 16:17: the Exchange Online incident (EX1550543) starts, according to third-party trackers, with users unable to open their mailboxes.
• 17:43 to 18:15: UK reports on Downdetector jump roughly tenfold, with a spike for Teams at about 18:15. Microsoft posts that it is investigating mailbox access problems, at first describing “elevated load” in the Americas.
• Around 18:00 to 18:30: US reports for Outlook peak at about 138,000 on Downdetector, one of the largest spikes the service has recorded for Microsoft. Microsoft opens the wider incident, MO1550821, at 18:26.
• 19:18: Microsoft says the elevated load “isn’t driven by an increase in traffic, but by a number of servers being unexpectedly unavailable”.
• 19:57: Microsoft says it has not found any recent change that correlates with the start of the impact.
• Thursday evening: Microsoft pauses deployments, moves traffic away from affected infrastructure and restarts servers. It says servers are failing automated health checks, tests a configuration change, and brings a subset of servers back with “an alternative service health check method”. It then admits the actions “have not provided the anticipated relief”, and explains that a core process on affected servers, the one that establishes secure connections, is becoming overwhelmed.
• Late Thursday: recovered servers fail again. Microsoft: “The servers we returned to service can become unresponsive again once they receive traffic; we’re analyzing diagnostic data.” It restricts some types of traffic, reports partial recovery in some regions, and then says the changes are “not taking as expected”.
• Overnight into Friday: Microsoft starts reverting “a recent network configuration change that correlates with the start of impact”, reversing its earlier statement that no change was involved. Server restarts show some improvement, but recovery is not sustained.
• Friday 13 November, morning: the outage passes 12 hours. UK reports climb again as people start work, with London highest. Microsoft says users may still be unable to connect and gives no time for full restoration.

#What Microsoft has actually said about the cause

It is worth separating what Microsoft has confirmed from what people are guessing.

Confirmed by Microsoft:

• The load was caused by servers becoming unexpectedly unavailable, not by a rise in traffic.
• A process on the affected servers that is responsible for establishing secure connections became overwhelmed, and the servers stopped processing requests.
• The affected servers were failing automated health checks.
• Servers returned to service can become unresponsive again once traffic reaches them, and Microsoft did not yet know what triggers this.
• A configuration change and an alternative health-check method brought back some servers, but the recovery did not hold.
• Microsoft is reverting a recent network configuration change that correlates with the start of the impact.
• There is no sign of a cyberattack.

Not yet known: the root cause. “Correlates” is not “caused”: Microsoft has not said the network change triggered the outage, only that its timing matches, and the incident still lists no root cause. Notice also that its account changed within hours, from “no recent change” at 19:57 to rolling one back overnight. Microsoft publishes a post-incident review for incidents of this size, and that is where the real answer should appear. Anything that names a definite root cause today is speculation, including the analysis in the next section.

#Our view: what has probably gone wrong

Microsoft’s description fits a well-known failure pattern in large cloud services, a cascading overload that feeds itself. This is our reading of the public facts, not Microsoft’s diagnosis.

#

1. Something took servers out of service

The first thing Microsoft established is that servers dropped out unexpectedly, and the survivors were left carrying their load. A network configuration change that cut some servers off, or made them look unhealthy, would produce exactly that pattern, which is why the rollback matters. It would also explain why restarting servers alone did not help: if the network change was still in place, the conditions that knocked them out were still there.

#

2. The expensive part of every connection broke first

Setting up a secure (TLS) connection costs far more processing than sending data over one that already exists. Normally most Outlook and Teams clients hold long-lived connections, so the handshake cost is spread out. When something forces clients to reconnect at once, every one of those millions of clients pays the handshake cost at the same moment. A process that copes comfortably in normal running can be swamped.

#

3. Health checks then made it worse

When a server stops answering its health checks, the load balancer takes it out of rotation. Its traffic moves to the servers that are left, which pushes them over the same limit, and they fail their checks too. Microsoft’s decision to test a workaround that bypasses the health-check component suggests it sees this loop: the safety mechanism designed to remove a sick server was removing healthy capacity faster than it could be restored.

#

4. Recovery was hit by a reconnection storm

This explains the most telling detail, that servers fall over again “once they receive traffic”. A freshly restored server does not get a normal share of traffic. It gets every Outlook client, phone and Teams app that has been retrying for hours, all at once, all needing a new secure connection. That spike is far larger than the server’s normal load, so it fails, and the clients retry again. Engineers call this a thundering herd. It is why fixes that worked on a small test group did not hold when rolled out wider.

#

5. One shared layer, many products

The spread of the outage, from mail to Teams to SharePoint to Copilot, points to a shared front-door or connection layer rather than a fault inside Exchange alone. Microsoft 365 services share authentication, networking and edge infrastructure, which is efficient in normal running and a single point of pain when that layer fails. The damage reached beyond Microsoft’s own apps too: Anthropic and OpenAI both reported problems with their Microsoft 365 connectors during the incident.

#How Microsoft can fix it

For the immediate recovery, these are the levers we would expect Microsoft to be pulling, roughly in order.

1. Reverse the trigger everywhere. If the network configuration change is the cause, rolling it back across the whole fleet is the fastest route to a stable service. Microsoft has started this; how quickly it completes will decide how long the outage lasts.
2. Bring traffic back slowly. Let restored servers admit only a fraction of normal traffic, and raise it in steps. Microsoft has already restricted some traffic types. Gating traffic at the edge by region, tenant or client type stops the reconnection spike that has been killing recovered servers.
3. Shed load deliberately. It is better to refuse some connections cleanly, with a “retry later” response that tells clients how long to wait, than to accept everything and fail for everyone.
4. Separate health checks from the overloaded path. A server that is recovering should not be removed from service because the same struggling component also answers its health check. Microsoft’s “alternative service health check method” looks like exactly this.
5. Add capacity where the handshakes happen. More capacity for the secure-connection process, or moving that work to a layer that can scale out, buys headroom while the root cause is found.

For the longer term, the lessons are architectural:

• Smaller blast radius. Cells or regional partitions that fail independently would have kept a fault in one part of the edge from taking down several products worldwide.
• Retry behaviour in Microsoft’s own clients. Outlook, Teams and the mobile apps should back off with randomised delays (jitter) after repeated failures, so that recovery does not trigger a stampede. Client behaviour is part of service resilience.
• Test recovery, not only failure. Failure drills that cover a cold restart under full client load would show whether a service can come back, not just whether it can fail over.
• Safer network changes. If a network configuration change is confirmed as the trigger, the question is how it reached enough of the fleet to cause a global outage. Changes should go out in small stages, each one watched for harm before the next, with automatic rollback. The October 2025 Azure Front Door outage raised the same question.
• Better communication. Updates posted on X and in the admin centre were slow to explain what was happening, and the “no recent change” statement had to be reversed within hours. Administrators need clear restoration estimates, honest confidence levels and a public post-incident review with dates.

#The impact

Downdetector figures understate an outage of this kind, because most affected users do not report it. About 138,000 US reports for Outlook at the peak still shows the scale. Microsoft 365 is the default communication layer for most UK organisations, from small firms to councils, schools, universities and NHS bodies, so a failure of this size reaches far beyond email.

• Communication stops. Mail, chat and meetings fail together, and many organisations have no second channel set up.
• Sign-in-dependent work stalls. Anything that relies on SharePoint or OneDrive files, Teams phone, approvals or shared mailboxes is affected even when the underlying business system is fine.
• Security operations lose visibility. Where Defender XDR, Intune or Purview are degraded, security teams lose some of their tools. Defender for Office 365 Safe Links may be unable to check URLs, which weakens link protection just when phishing that exploits the outage is likely.
• Integrations break. Third-party tools that read or send through Microsoft 365 failed in turn, including the Microsoft 365 connectors of OpenAI and Anthropic.
• Real operations are hit. In India, SpiceJet cancelled three flights from Delhi and delayed others, and IndiGo and Akasa Air reported email and support disruption. In Canada, VIA Rail warned passengers that trip emails might not arrive, and hospitals reported disruption to email.

For UK organisations, the timing softened the first blow: the worst of it began around the end of the working day on Thursday. The cost lands on Friday, with a full working day on a degraded service and the end-of-week work that depends on email. Friday is also the busiest day for house completions, and conveyancers and mortgage brokers have warned that completions which depend on emailed confirmations and fund transfers are at risk. Law firms have reported disruption too.

#What to do now

1. Check Service health, not users’ machines. In the Microsoft 365 admin centre, open Health > Service health and follow EX1550543 and MO1550821. If the admin centre itself will not load, use the public status page at status.cloud.microsoft and Microsoft’s @MSFT365Status account on X.
2. Stop local fixes. Do not reset passwords, rebuild Outlook profiles, reinstall Office or clear caches. None of it helps, and a rebuilt profile loses its cached mail until the service returns.
3. Tell people early and plainly. Send a short notice by a channel that does not depend on Microsoft 365 (SMS, an intranet that is not hosted on SharePoint, a phone cascade). Teams chat may work today, but it shares infrastructure with Outlook, so do not rely on it as your only fallback. The message: Microsoft has a global outage, it is not our systems, here is how to reach us, we will update you at a set time.
4. Use what still works. Outlook desktop in Cached Exchange Mode still shows mail and calendar items already downloaded. Files synced locally by OneDrive stay available offline. Phone calls still work for urgent conversations.
5. Expect delayed mail, not lost mail. Mail servers that cannot deliver to Exchange Online retry for hours or days under the SMTP standard, so most inbound mail should arrive late. Warn anyone waiting for time-critical messages, and ask important senders to confirm by phone.
6. Watch for outage-themed phishing. Expect fake “restore your Microsoft account” and “verify your mailbox” emails and texts, and remember that Safe Links checks may not be working. Remind staff that Microsoft will not ask them to sign in through a link to fix this.
7. Hold risky changes. Do not push Intune policies, conditional access changes or mail flow changes while the service is unstable. You cannot verify their effect, and they add confusion when the service returns.
8. Keep a log. Record when your users lost each service and when it returned, and what it cost you. You will need it for the service credit claim and your own review.

#After recovery

• Claim service credits. Microsoft 365 services carry a financially backed 99.9% monthly uptime commitment, which allows about 43 minutes of downtime in a 30-day month. An outage measured in hours breaches it by a wide margin for affected users. Credits are not automatic: open a claim through the admin centre with the incident IDs and your evidence, within the deadline in Microsoft’s Service Level Agreement for Online Services. Credits are a percentage of the affected service’s monthly fee, so they will not cover your real cost, but claiming them is how customers register the breach.
• Read Microsoft’s post-incident review. Microsoft publishes reviews for major incidents in the admin centre. Check whether it names the trigger, what changes it commits to, and dates for them.
• Write down your fallback plan. Decide now which channel you use when Microsoft 365 is down: a group SMS tool, a secondary chat platform, a status page or a phone tree. Make sure the contact list for it is not stored only in Outlook.
• Keep critical documents reachable offline. Business continuity plans, supplier contacts and incident runbooks that live only in SharePoint are unreachable at exactly the moment you need them.
• Review your dependency on one provider. Few organisations should leave Microsoft 365 over one outage. But a fallback that moves people from Outlook to Teams is not a fallback, because both depend on the same infrastructure. Ask whether an email continuity service, a second messaging or meetings tool for critical teams, or keeping some systems independent of Microsoft is worth the cost for your business.

#Is this becoming a pattern?

This is not an isolated event. In January 2026 a Microsoft 365 outage (MO1221364) ran for about ten hours after part of the North American infrastructure stopped processing traffic; Microsoft blamed elevated load during maintenance that had reduced capacity. In October 2025 an inadvertent configuration change to Azure Front Door, Microsoft’s global edge network, took down Azure and Microsoft 365 services worldwide for more than eight hours. In January 2023 a global Teams and Outlook outage was fixed by rolling back a network change. In July 2024 a faulty CrowdStrike update crashed around 8.5 million Windows machines, which was not Microsoft’s own failure but showed how much depends on its platform.

The common thread is concentration. A handful of shared layers, such as edge networks, identity and connection handling, now sit underneath most of the world’s office work, and each failure in them reaches millions of people at once. Microsoft runs these services well most of the time, and no provider at this scale avoids outages entirely. But the size of this incident, and the time it is taking to recover, mean customers are entitled to a detailed account of the trigger and of the engineering changes that will stop recovery itself becoming the problem next time.

#The short version

• A global Microsoft 365 outage centred on Exchange Online began late on Thursday 12 November, UK time, and was still not fully fixed on Friday.
• Microsoft says servers went unexpectedly offline and an overloaded secure-connection process stopped the rest handling requests. It is not a cyberattack. Microsoft is reverting a network configuration change that correlates with the start, but has not confirmed a root cause.
• Recovery is hard because restored servers fail again under the flood of reconnecting clients.
• Do not troubleshoot locally. Follow EX1550543 and MO1550821 in Service health, tell users, use offline copies and other channels, and watch for phishing.
• Afterwards, claim service credits, read the post-incident review, and make sure your fallback plan does not depend on Microsoft 365 being up.

We will update this article as Microsoft confirms full restoration and publishes its review.