Microsoft 365 Outage: How Failed Health Checks Broke Outlook

The Microsoft 365 outage of November 12–13, 2026 is one of the largest this year, and it is a textbook case of a failure that feeds itself. It started around 1 p.m. ET on Thursday, when users could not reach Outlook mailboxes on the web, desktop or mobile. By Friday morning in London it was still running, and Microsoft had given no estimated time for recovery. Most coverage has focused on what broke and how many people complained. This article goes further. It explains the mechanism Microsoft has described, in plain terms. It shows why “just restart the servers” did not work. And it gives practical steps for three groups: everyday users, Microsoft 365 admins, and developers whose apps or AI agents call Microsoft Graph. To make the mechanism concrete, I ran a small Node.js simulation of a health-check death spiral, which you will find below. Everything else comes from Microsoft’s own status updates, as reported by named outlets.

What happened in the Microsoft 365 outage?

The Microsoft 365 outage began when users in the Americas could not connect to Exchange Online mailboxes, and it quickly widened to every region. Microsoft opened Exchange incident EX1550543 at 16:17 GMT on November 12. At 18:07 GMT it warned the issue “may affect Microsoft 365 service connectivity for users in any region.” At 18:26 GMT it opened a broader incident, MO1550821, covering the rest of the suite (UC Today timeline).

Timeline of Microsoft’s updates

1. Early afternoon ET: Downdetector showed about 119,000 Outlook reports, down slightly from a peak of 130,000.
2. Load diagnosis: Microsoft said the elevated load “isn’t driven by an overall increase in traffic, but by a large number of servers being unexpectedly unavailable” (Microsoft status update via Tom’s Guide).
3. 19:06 GMT: Microsoft paused all deployments and configuration changes.
4. Health-check finding: Microsoft said affected servers were failing automated health checks, and it tested a workaround that bypassed the component processing those checks (SecurityWeek).
5. Partial fix: An alternative health-check method returned a subset of servers to service, and Microsoft began applying it more broadly (Tom’s Guide).
6. Relapse: Microsoft warned restored servers “can become unresponsive again once they receive traffic” and limited which traffic could reach them (Tom’s Guide).
7. 04:10 GMT Friday: Partial recovery in some regions, but actions were not resulting in sustained recovery.

Microsoft also began reverting “a recent network configuration change that correlates with the start of impact,” according to UC Today. That is a candidate cause, not a confirmed one. Treat any article that names a definitive root cause today with suspicion.

Which Microsoft 365 apps were affected?

Exchange Online was the centre of the outage, so anything that depends on it broke too. Outlook failed in the browser, on the desktop and on mobile, and Microsoft said inbound mail may be delayed (UC Today). Microsoft also flagged potential disruption to Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR (SecurityWeek).

Teams: partly up, partly down

Teams showed the dependency map clearly. Calls, meetings, group chats and standard channels largely kept working. Calendars, scheduling, invites, meeting edits, contact sync and private-channel changes did not, because they rely on Exchange (UC Today).

AI tools and connectors

Microsoft 365 Copilot chat could fail to load or fail to reach email, calendar and files. Power Platform advisory PP1550869 said flows, apps and Copilot Studio connectors relying on Graph failed intermittently. OpenAI and Anthropic both reported problems with their Microsoft 365 connectors (CIO&Leader). If you build AI agents on top of Microsoft data, your agent was down too, even though your own servers were fine. Our guide to single vs multi-agent orchestration covers how to design agents that degrade instead of failing outright.

Was the Microsoft 365 outage a cyberattack?

No evidence points to a cyberattack. Charles Lamanna, Microsoft’s Executive Vice President for Business and Industry Copilot, posted that “there is no indication this is the result of malicious or cyber activity.” Microsoft’s service-health notes said the same (UC Today).

Some readers linked the outage to November’s Patch Tuesday, which addressed 1,094 vulnerabilities, including the exploited Outlook spoofing flaw CVE-2026-124194. SecurityWeek notes that Microsoft’s advisories have not linked that vulnerability to the Exchange Online outage (SecurityWeek). Do not build your incident response around that theory.

How do failed health checks cause a Microsoft 365 outage?

Failed health checks cause an outage when the system that removes “sick” servers removes too many at once. A load balancer pings each server and stops sending traffic to any that fail. That is useful for one broken machine. It becomes dangerous when many servers fail for the same shared reason.

The death spiral, step by step

1. Some servers fail their health checks and are removed from service.
2. Total traffic stays the same, so each remaining server gets a bigger share.
3. Busier servers respond more slowly, including to health checks.
4. Slow health-check answers count as failures, so more servers are removed.
5. The loop repeats until the fleet stabilises, or collapses.

Amazon’s Builders’ Library describes exactly this: taking servers out during overload “can cause a downward spiral,” because the remaining servers take more traffic and become more likely to fail their own checks (Implementing health checks). Microsoft’s own wording fits the pattern. A process that “sets up secure connections becomes overwhelmed, causing the servers to stop processing requests” (UC Today). Google’s SRE book names overload as the most common cause of cascading failures (Addressing Cascading Failures).

What our simulation shows

We built a toy model in Node.js v22.23.4: 100 servers, each able to handle 100 units, carrying 7,000 units of traffic. An overloaded server answers health checks too slowly, so a quarter of overloaded servers get pulled each round. This is not Microsoft’s architecture. It only illustrates the feedback loop.

// Toy model of a health-check death spiral (not Microsoft's real fleet)
const N = 100, CAP = 100, TRAFFIC = 7000;   // 100 servers, 70% average utilisation

function run({ initialFailures, minHealthyFraction = 0 }) {
  let healthy = N - initialFailures;
  for (let round = 0; round < 20; round++) {
    const perServer = TRAFFIC / healthy;
    console.log({ round, healthy, perServer: Math.round(perServer) });
    if (perServer <= CAP) return 'stable';
    // Overloaded servers answer health checks too slowly; 25% get pulled each round
    const floor = Math.ceil(N * minHealthyFraction);         // the "breaker"
    const removed = Math.min(Math.ceil(healthy * 0.25), Math.max(0, healthy - floor));
    if (removed === 0) return 'breaker holds (degraded, but serving)';
    healthy -= removed;
    if (healthy <= 0) return 'total outage';
  }
}

$ node spiral.mjs        # Node.js v22.23.4, toy model: 100 servers, 70% average utilisation

35 servers lost, no breaker
round  healthy  loadPerServer
0      65       108
1      48       146
2      36       194
3      27       259
...
12     1        7000
13     0        Infinity

20 servers lost, no breaker
round  healthy  loadPerServer
0      80       88          # stable: the fleet absorbs it

35 servers lost, breaker at 60%
round  healthy  loadPerServer  note
0      65       108
1      60       117
2      60       117            breaker holds

The result is a cliff, not a slope. Losing 20 servers was absorbed. Losing 35 sent the toy fleet to zero in 13 rounds. Adding a floor that refuses to remove more than 40% of the fleet kept 60 servers serving, overloaded but alive. Microsoft took a similar step: it said it had “taken steps to prevent additional servers from being removed from service” (Tom’s Guide).

Why did Microsoft’s restarts not fix Outlook?

Restarts did not hold because a freshly restarted server is weaker than a warm one, yet it receives a full share of traffic immediately. Microsoft said restored servers became unresponsive again once traffic returned. It later said mitigations caused “a surge of calls from routing services to backend servers” (UC Today).

Our second simulation shows how narrow the recovery window is. Assume 40 warm servers and 60 restarted ones that can only take 50 units in their first minute, because caches are cold and secure sessions must be rebuilt.

Recovery: 40 warm servers + 60 restarted (cold capacity 50, warm capacity 100)
loadSentToRestarted  warmServerLoad  outcome
70 (even share)      70              restarted servers overload again
40 (too cautious)    115             warm servers overload
50 (matched ramp)    100             stable

Send restarted servers an even share and they fall over again. Send them too little and the warm servers overload instead. Only a matched ramp is stable. This is why Microsoft limited which types of traffic could reach affected infrastructure (Tom’s Guide). Shedding or throttling traffic is often the only way to give the fleet room to recover.

How do I fix Outlook while Microsoft 365 is down?

You cannot fix this outage from your device, because the failure is in Microsoft’s servers. What you can do is avoid making things worse and keep working.

For users

1. Check the status first at status.cloud.microsoft or the @MSFT365Status account on X.
2. Do not reinstall Outlook, delete your profile or reset your password. None of these touch the server-side fault.
3. Use classic Outlook with Cached Exchange Mode to read mail already synced; by default, 12 months of email is available offline.
4. Use Teams chat and calls for urgent conversations; Microsoft says those paths largely kept working (UC Today).
5. Assume mail is delayed, not lost, and check for missing messages after recovery.

For admins

1. Track EX1550543, MO1550821 and PP1550869 in the admin center (UC Today).
2. Note that Safe Links may fail to process rewritten URLs during the incident (UC Today).
3. Send staff and customer updates through an out-of-band channel that does not depend on Exchange.
4. Do not loosen security policies to create a workaround.

What should developers learn from this outage?

Developers should learn that retries during a provider outage are load, and badly behaved clients can extend the outage. Microsoft’s own explanation of the relapse involved a surge of calls to backend servers. Your integration is one of millions of clients hitting the same recovering service.

Microsoft’s Graph throttling guidance says to wait the number of seconds in the Retry-After header before retrying, and to use exponential backoff when no header is sent. Here is a minimal Node.js client that follows that guidance, caps attempts and adds jitter so clients do not retry in lockstep.

// Calling Microsoft Graph during an incident: respect Retry-After, cap attempts, add jitter
async function graphFetch(url, token, { maxAttempts = 5 } = {}) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    const res = await fetch(url, {
      headers: { Authorization: `Bearer ${token}` },
      signal: AbortSignal.timeout(10_000),          // never hang a worker on a sick backend
    });
    if (res.ok) return res.json();
    const retryable = res.status === 429 || res.status === 503 || res.status === 504;
    if (!retryable || attempt === maxAttempts) {
      throw new Error(`Graph ${res.status} after ${attempt} attempt(s)`);
    }
    const retryAfter = Number(res.headers.get('retry-after'));        // seconds, if sent
    const backoff = Math.min(30_000, 2 ** attempt * 500);             // exponential fallback
    const waitMs = (retryAfter > 0 ? retryAfter * 1000 : backoff) * (0.5 + Math.random());
    await new Promise((r) => setTimeout(r, waitMs));
  }
}

Pair this with idempotent writes, so a retried “send” or “create event” does not duplicate work. Our idempotency keys guide shows the pattern. For read-heavy dashboards, cache the last good Graph response and show it with a “data may be stale” banner instead of an error page. Our API performance checklist covers caching and timeouts in more depth. Python developers using the Graph SDK get Retry-After handling built in, since Microsoft Graph SDKs already implement it.

What worked and what failed (November 12–13, 2026)

Service or feature	Status reported	Why	Source
Outlook (web, desktop, mobile)	Down or degraded	Exchange Online servers failing health checks	UC Today
Inbound email	Delayed	Exchange Online capacity loss	UC Today
Teams calls, meetings, chats	Largely working	Not dependent on Exchange	UC Today
Teams calendars and scheduling	Failing	Exchange-dependent	UC Today
Microsoft 365 Copilot	May not load or reach mail	Exchange and Graph dependent	UC Today
Power Platform Graph connectors	Intermittent failures	Graph dependent (PP1550869)	UC Today
Files stored in SharePoint	Available	Storage not on the failing path	UC Today
Azure	No issues shown	Separate status page	UC Today

• The outage began around 1 p.m. ET on November 12, 2026, and was still not fully resolved on the morning of November 13.
• Microsoft said the elevated load came from servers becoming unavailable, not from an overall increase in traffic.
• Affected Exchange Online servers failed automated health checks, and Microsoft tested an alternative health-check method to return them to service.
• Restarted servers became unresponsive again once traffic returned, so Microsoft limited traffic to affected infrastructure.
• Microsoft said there was no indication of malicious or cyber activity, and no root cause was confirmed at the time of writing.
• Teams calls and chats largely worked, while Exchange-dependent features such as calendars and Copilot mail access failed.

Frequently Asked Questions

Why is Microsoft Outlook not working today?

Outlook is affected by a Microsoft 365 outage that began on November 12, 2026. Microsoft says a large number of Exchange Online servers failed automated health checks and dropped out, overloading the rest. It is a service-side problem, so reinstalling Outlook or resetting passwords will not fix it.

Was the Microsoft 365 outage a cyberattack?

Microsoft says no. Executive Vice President Charles Lamanna posted that there is no indication the outage is the result of malicious or cyber activity, and Microsoft’s service-health notes say the same. The root cause had not been formally confirmed when this article was written.

How do I check Microsoft 365 service status?

Admins can track incidents EX1550543 and MO1550821 in the Microsoft 365 admin center. If the admin center does not load, Microsoft points users to the public status page at status.cloud.microsoft and the @MSFT365Status account on X, which posted updates throughout the incident.

Will I lose emails during the Outlook outage?

Microsoft says inbound mail may be delayed. Delayed is not the same as lost: senders’ mail servers normally queue and retry delivery. Check for missing messages after recovery, and ask important contacts to resend only if something has still not arrived once service is stable.

Is Microsoft Teams down too?

Partly. Microsoft says Teams calls, meetings, group chats and standard channels largely kept working. Features that depend on Exchange, such as calendars, scheduling, invites, meeting edits and contact sync, were affected. A separate Teams incident earlier on November 12 was resolved.

Conclusion

The November 2026 Microsoft 365 outage is a reminder that the scariest failures are not caused by one broken server. They come from a protective system reacting to a shared problem in the same way, everywhere, at once. Microsoft’s updates point to health checks pulling servers, the survivors overloading, and restarts relapsing under full traffic. For users, the advice is simple: check status, use Teams chat, and wait. For admins, keep an out-of-band channel ready. For developers, respect Retry-After and design your apps and AI agents to degrade gracefully when Graph is down. We will update this post when Microsoft publishes its post-incident review.

Sources

• UC Today — Microsoft 365 Outage: Outlook Down, and the Fix Won’t Hold
• SecurityWeek — Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams
• CIO&Leader — Microsoft Outlook outage runs into Friday as recovery stalls
• Tom’s Guide — Outlook, Microsoft 365, Teams and more down: live updates
• Charles Lamanna (Microsoft) — statement on X
• Microsoft — Microsoft 365 service status page
• Microsoft Learn — Microsoft Graph throttling guidance
• Microsoft Support — Turn on Cached Exchange Mode
• Amazon Builders’ Library — Implementing health checks
• Google SRE Book — Addressing Cascading Failures