Executive summary
On the evening of 12 November 2026 (IST), a failure in Exchange Online grew into a global Microsoft 365 outage. It cut off Outlook email and disrupted Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR for organisations in every region. More than 11 hours after impact began, Microsoft had achieved only partial recovery and had not confirmed a root cause or a restoration time.
Microsoft said the load was not caused by a rise in traffic. Some servers became unexpectedly unavailable, their work shifted to the remaining servers, and a process on those servers that establishes secure connections became overwhelmed. Microsoft has not attributed the outage to malicious activity.
Customers cannot prevent a provider outage, but they can control what it costs them. This paper explains what happened and what it disrupted, then sets out three things: a five-part resilience framework any organisation can adopt within 30 days, the engineering practices that keep cloud products running when a provider fails, and how Upperthrust applies them for its clients.
Key findings
- A single provider-side failure disrupted email, scheduling, file features and security link-checking at the same time.
- The failure behaved like a capacity cascade: losing some servers overloaded the rest, and servers returned to service failed again under load.
- Organisations with a second communication channel, offline contacts and briefed staff were best placed to keep working.
- The same cascade pattern can affect any product built on cloud infrastructure, and it can be designed against.
1. Incident overview and timeline
Microsoft tracks the outage as EX1550543 (Exchange Online) and MO1550821 (Microsoft 365 services that depend on Exchange Online). A separate Teams incident, TM1550488, affected users in the Americas earlier the same day and was resolved. Times below are IST, newest first, compiled from Microsoft's status updates as reported publicly; they are current to Microsoft's updates published by 9:30 AM IST on 13 November 2026.
| Time (IST) | Event |
|---|---|
| 13 Nov, mid-morning | Microsoft says machines stuck in a bad state are preventing its configuration changes from syncing. |
| 13 Nov, 8:37 AM | Microsoft confirms a remediation change is 'not taking as expected' and looks for other ways to add capacity. |
| 13 Nov, 7:20 AM | Microsoft reports 'positive results' from restarting affected infrastructure and plans to expand the fix. |
| 13 Nov, before 7:20 AM | Cause narrowed: a process that establishes secure connections becomes overwhelmed, so servers stop processing requests. Microsoft begins reverting a recent network configuration change that correlates with the start of impact. |
| 13 Nov, 5:30 AM | Returned servers can become unresponsive again once they receive traffic. Some servers are rebuilt with a previous software configuration. |
| 13 Nov, 4:27 AM | Limited recovery as traffic shifts to alternate routes. |
| 13 Nov, 3:30 AM | Microsoft says its actions 'have not provided the anticipated relief' and that a core process on affected servers is overwhelmed. |
| 13 Nov, 2:26 AM | An alternative health-check method returns a subset of servers to service. |
| 13 Nov, 1:13 AM | Affected servers fail automated health checks and are taken out of service. |
| 13 Nov, 12:48 AM | Microsoft says the load is not from more traffic: some servers became unexpectedly unavailable and their work moved to the rest. |
| 13 Nov, 12:36 AM | Microsoft pauses all deployments and configuration changes. |
| 12 Nov, 11:56 PM | Incident MO1550821 opens for dependent services, with impact possible in any region. |
| 12 Nov, 11:49 PM | Microsoft reports elevated load across multiple regions and starts restarting servers. |
| 12 Nov, about 11:30 PM | Outlook problem reports on Downdetector peak near 130,000. |
| 12 Nov, about 9:45 PM | Exchange Online mailbox access failures begin (EX1550543). |
| 12 Nov, 8:15–9:23 PM | Separate Teams incident TM1550488 in North and South America; resolved. |
Affected services listed by Microsoft: Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR, Defender for Office 365, Planner, To Do, Intune, Purview and Power BI.
2. What went wrong: a capacity cascade
The outage behaved like a cascading failure: losing some capacity overloaded the rest, and the same mechanism slowed recovery. The loop below is Upperthrust's reading of Microsoft's public status updates. Each turn of the loop removed more capacity:
- 1. Servers drop out. Some servers become unavailable and fail automated health checks.
- 2. Load shifts. Their traffic moves to the remaining servers.
- 3. A core process is overwhelmed. The secure-connection process on those servers is overloaded.
- 4. More servers stop. They stop processing requests and fail health checks in turn, and the loop returns to step 1.
This loop explains why servers returned to service became unresponsive again once they received traffic, and why recovery stayed partial for hours.
Microsoft said it was reverting a recent network configuration change that correlates with the start of impact, but it has not confirmed that change as the root cause. Early in the incident, Microsoft also said the failed health checks might originate from a specific component that processes server health. The final root cause is expected in Microsoft's post-incident review.
Upperthrust's engineering view: whatever the trigger, health checks that remove servers faster than the remaining fleet can absorb their load can deepen an overload instead of containing it. Section 5 sets out practices that break this loop.
3. Business impact
Email was the hardest hit, and every workflow that depends on email failed with it.
| Area | What users experienced |
|---|---|
| Email (Exchange Online) | No mailbox access through Outlook on the web, Outlook desktop, mobile (Exchange ActiveSync) or REST-based apps; delayed delivery. |
| Teams | Calendar, scheduling and other features that depend on Exchange Online did not work consistently. |
| Files | Files stored directly in SharePoint Online stayed reachable, but Exchange-dependent features were unreliable. |
| Copilot | Copilot Chat could fail to load or respond, and could not reach work data such as email, calendar and files. |
| Security | Defender for Office 365 Safe Links could not always verify URLs clicked in Outlook and Teams. |
| Productivity | Planner, To Do and Intune were also listed as affected. |
Reported effects included stores losing email-based sales, patients losing access to telehealth services, distance-learning schools closing for the day and courts losing live feeds. For a typical knowledge-worker organisation, a working day without email means stalled sales, missed customer responses, delayed approvals and invoices, and a backlog that takes days to clear.
4. A five-part resilience framework
These five measures reduce the business cost of any provider outage, and most organisations can put them in place within 30 days.
| Pillar | What to do | Effort |
|---|---|---|
| 1. Detect early | Turn on Microsoft 365 service health email alerts for admins; follow status.cloud.microsoft and @MSFT365Status; add an independent monitor so you do not depend on the provider's own admin center. | Low |
| 2. Communicate on a second channel | Agree a fallback for when email fails (a chat tool on a different provider, SMS, WhatsApp Business or a phone tree) and a status page or banner for customers. | Low |
| 3. Keep critical data reachable | Keep an offline or printed list of key client, vendor and staff contacts; store critical documents where they open without the affected service. | Low |
| 4. Protect against outage-time scams | Brief staff in advance: during outages, never reset passwords or install tools on request, and verify any 'IT help' through known numbers. | Low |
| 5. Reduce single-provider dependency | Map which business processes depend on Exchange Online and Entra ID; for the most critical, add a secondary path (for example a mail continuity service at the gateway) and test it. | Medium |
Outage-day checklist
- Confirm the incident on the official status page before troubleshooting locally
- Tell staff not to reset passwords or reinstall Outlook
- Switch urgent communication to the agreed fallback channel
- Post a short customer notice on your website and social channels
- Warn staff about phishing and fake support calls
- Log business impact (missed orders, delayed responses) for the post-incident review
- After recovery, check for delayed or missing mail and review the provider's post-incident report
5. For engineering teams: building products that survive provider outages
The same failure pattern, servers dropping out and overloading the rest, can take down any product built on a cloud platform. These eight practices design against it.
| Practice | What it prevents |
|---|---|
| Load shedding and rate limiting | Rejects excess requests early, so an overload degrades service instead of collapsing it |
| Health checks that don't amplify failure | Caps how many instances can be removed at once, so health checks never pull most of the fleet under stress |
| Circuit breakers, timeouts and retries with backoff and jitter | Stops retry storms that pile more load onto a struggling dependency |
| Graceful degradation | Keeps core features running when a dependency such as email, identity or AI fails, as files stored directly in SharePoint stayed reachable during this outage |
| Multi-region and multi-provider failover for critical paths | Removes single points of failure from the flows that earn revenue |
| Progressive delivery, change freezes and fast rollback | Limits how far a bad network or configuration change can spread and makes it quick to undo; Microsoft paused all deployments and configuration changes within about an hour of opening the wider incident |
| Chaos engineering and game days | Finds cascading failures in a test, not in production |
| SLOs, observability and runbooks | Detects issues before users do and gives on-call teams a tested response |
6. How Upperthrust keeps its clients running
Upperthrust maintains on-premises backups of critical client data alongside the cloud, so a cloud provider outage does not cut clients off from the data their business depends on. That backup is the base of a hybrid resilience model that combines local control with cloud-native engineering.
| Layer | How Upperthrust handles it | Why it matters in an outage |
|---|---|---|
| On-premises backup | Critical data is backed up on-premises, independent of any single cloud provider | Data stays reachable and restorable while the cloud service is down |
| Infrastructure as Code | Environments are defined in code and version-controlled | Systems can be rebuilt quickly in another region or on another platform |
| CI/CD with controlled releases | Changes ship through automated pipelines with staged rollout and rollback built in | A bad release or configuration change can be stopped early and rolled back quickly |
| Kubernetes platforms | Workloads run on orchestrated, self-healing clusters, deployed across zones or regions for critical services | Failed instances are replaced automatically, without waiting for manual intervention |
| 24/7 managed DevOps | Round-the-clock monitoring and operations | Issues are detected and acted on at any hour, not the next business day |
| Certified security (DevSecOps) | Security built into every stage of delivery; ISO/IEC 27001:2022 certified, SOC 2 attested and appraised at CMMI Level 3 | Reduces the risk that outage-time scams or rushed fixes turn into security incidents |
The result for clients: when a provider fails, their critical data is protected on-premises, their platforms can fail over or be rebuilt from code, and an Upperthrust team is already watching.
7. Conclusion
The November 2026 outage needed no traffic spike to stop work for organisations around the world: servers dropping out of a shared platform was enough. The organisations best placed to cope already had a second communication channel, offline contacts and staff who knew not to 'fix' a provider-side problem locally. The products that hold up in events like this are designed to degrade, not collapse. Both are within reach of any organisation, and the next outage, at Microsoft or any other provider, is a matter of when, not if.
References
- Microsoft 365 Service health status (status.cloud.microsoft)
- BleepingComputer: Massive Microsoft 365 outage disrupts Outlook, Teams, Copilot worldwide
- ABC News (Australia): Microsoft outage drags on for hours, disrupting Outlook, Teams for thousands
- ABC News (Australia): Live coverage of the Microsoft outage
- CNN: Massive Microsoft outage disrupts businesses, schools and governments around the world
- Gizmodo: Microsoft 365 outage stretches late into the evening
- 1News: Network change coincided with Microsoft outage
- ABC7: Microsoft outage live updates
- Forbes Australia: Microsoft's fixes fail as outage passes 10 hours
- Azure Blog: Microsoft 365 outage, 12 November 2026
Information is accurate as of 9:30 AM IST, 13 November 2026. Microsoft had not published a root cause at the time of writing; this paper will be updated after Microsoft's post-incident review.