On Thursday 12 November 2026, at 16:17 UTC, people began losing access to their Outlook mail. The service behind it is Exchange Online, the part of Microsoft 365 that stores and delivers Outlook mail, calendars and contacts. On the US East Coast it was 11:17 in the morning; in India it was 21:47. Twelve hours later it was still not fixed, and Microsoft had listed 18 other services as affected, from Teams calendars to Copilot and Intune.

The most interesting thing Microsoft said came at 19:18 UTC, about three hours in. The load was not coming from more users. Traffic had not grown. Servers were dropping out, and the ones left behind could not carry the work. This article walks through what Microsoft said, update by update, what I saw when I probed its servers during the outage, and why an overload like this can keep a service down long after the first cause is found. It ends with the safeguards I would add to my own services because of it.

Where things stood when the explainer was last checked

At 00:31 UTC on 14 November, Microsoft listed the incident as recovering, not yet closed. It said it continued to observe sustained service recovery across the affected environments, that it was monitoring for an extended period because of how severe the impact was, and that it was working through the backlog of email that built up during the outage before calling the issue resolved. It also said it believed most of the affected scenarios in the other Microsoft 365 services had been addressed. Microsoft had not published a root cause, and it has said it will publish a Post-Incident Report. Nothing below is a claim about the final cause.

What happened

At 16:17 UTC Microsoft opened incident EX1550543: users may be unable to connect to their mailboxes in Exchange Online through multiple connection methods. The methods it named are the ones nearly everybody uses: Outlook in a browser, Outlook installed on a computer (which talks to Exchange with Microsoft's own MAPI protocol), the mail apps on phones (which use Exchange ActiveSync) and programs that read mail through Microsoft's web API (REST). Microsoft also said email delivery may be delayed.

Two hours later, at 18:26 UTC, Microsoft opened a second notice, MO1550821, for the rest of Microsoft 365. By the morning of 13 November that notice listed 18 services besides Exchange Online, and Microsoft's status page for consumers said Outlook.com, OneDrive, OneNote, To Do, Teams and Microsoft 365 for the web were affected for personal accounts too.

Microsoft posted 23 updates on the Exchange incident in its first twelve hours. It paused all deployments and configuration changes, moved traffic between regions, restarted and rebuilt servers, tried a different health check, began reverting a recent network change and started blocking some traffic on purpose. At 03:34 UTC on 13 November it said there was "no indication this is the result of malicious activity".

"We've determined that 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."

Microsoft, incident EX1550543, update at 19:18 UTC on 12 November 2026

Why one mail service took 18 others with it

Exchange Online is where Microsoft 365 keeps every user's mail, calendar and contacts. Many other services call Exchange when they need that data. Teams asks Exchange for your calendar when you schedule a meeting. Copilot asks it for your email when you ask a question about your inbox. Microsoft Graph, the API that thousands of company apps use, passes mail and calendar requests through to Exchange. Defender for Office 365 checks mail and links that flow through Exchange.

So when Exchange stopped answering, every feature that needed it failed too, and Microsoft listed them service by service. The useful detail is in what kept working. Microsoft wrote that most of Teams' core functions, including calls, meetings, group chats and channel messages, were not affected, and that files stored directly in SharePoint still opened. Those features do not need Exchange. Engineers call the set of things that break when one part fails its blast radius, and this outage drew it clearly.

Exchange Online in the middle, servers overloaded, with dashed lines to the 18 services Microsoft listed as affected, including Teams, Copilot, Graph API, Intune, Planner, Purview and SharePoint

Microsoft listed 18 services whose features that interact with Exchange Online were affected. The list is parsed from Microsoft's status feed on 13 November 2026.

That is the first design lesson. A service that many others depend on needs the strongest protection against overload, because its failure is everyone's failure. And each service that depends on it should be built so that the parts which do not need it keep working. Teams' core chat and calls kept working because they do not need Exchange; the chat features that do, such as adding people to new chats, failed.

Twelve hours of updates, read as an engineer would

Microsoft's explanation changed as it learned more, and the order of the changes is the story.

At 18:19 UTC Microsoft reported elevated load across several regions. At 19:18 it corrected itself: traffic had not grown, but many servers were unexpectedly unavailable, so the rest carried their load. At 19:43 it found why they were unavailable: they were failing automated health checks and being taken out of service, possibly because of a recent change to the part that processes those checks. At 20:56 a different health check method brought some servers back.

Then it got harder. At 22:00 Microsoft said its actions had "not provided the anticipated relief" and that a core process on the servers was overwhelmed. At 23:59 it said servers it had returned to service "can become unresponsive again once they begin receiving traffic". At 01:06 on 13 November it named the process: the one "responsible for establishing secure connections". The same update said it was reverting a recent network configuration change that correlated with the start of the outage.

By 04:10 Microsoft was "adjusting traffic protocols, redistributing traffic, and applying strategic traffic blocking measures", with partial recovery that was not lasting. At 04:57 it added that its own routing services were sending a surge of calls to the backend servers, partly because of the traffic moves it had made during the event.

Timeline of ten Microsoft updates in UTC, from the incident opening at 16:20 through failing health checks, an overwhelmed secure connection process and traffic blocking at 04:10

Ten of the 23 updates on EX1550543, shortened to one line each. Microsoft records the impact as starting at 16:17 and posted its first update at 16:20.

Here is how those updates fit together. A health check is a small test a load balancer runs against each server, such as "answer this request within two seconds". A server that fails is taken out of rotation so users are not sent to a broken machine. That is good when one server is sick. It is dangerous when the check itself is wrong, or when servers fail it only because they are busy. Each server removed pushes more load onto the rest, they get slower, and they fail the check too. Microsoft's 19:57 update says it took steps "to prevent additional servers from being removed from service", which is exactly the brake on that loop.

Microsoft has not said this was the cause, and its final report may say something different. But several of its steps, stopping removals, bringing servers back slowly and limiting and blocking traffic, are the textbook answer to this kind of loop.

What Microsoft's servers did when I connected

While the outage was still on, I probed Microsoft's servers from a home internet connection in India. No account and no password: I sent only the connection handshake and, where that succeeded, one anonymous request with no login, the same thing a browser sends before it shows a login page.

First, one host at a time, I checked two steps separately. Step one is the TCP connection, the basic "can I reach you" handshake. Step two is the TLS handshake, where the client says hello and the server must answer before the client can send any request. For outlook.office365.com, TCP opened and the TLS handshake did not finish in 15 seconds. For graph.microsoft.com, both finished in under a third of a second.

$ ./handshake_check.sh == outlook.office365.com (40.104.146.194) 05:03:21Z TCP connect to 40.104.146.194:443: open TLS done after 0.000000s, HTTP 000, total 15.069710s curl exit 28: TLS handshake did not finish in 15 s == graph.microsoft.com (20.190.175.24) 05:03:36Z TCP connect to 20.190.175.24:443: open TLS done after 0.171402s, HTTP 301, total 0.273097s $ python3 summarize_probes.py 9 rounds, 04:54 to 05:41 UTC, 13 Nov outlook.office365.com 72 attempts, 46 addresses: tls-timeout 61, tcp-timeout 11 outlook.office.com 61 attempts, 47 addresses: tls-timeout 41, tcp-timeout 19, refused 1 outlook.live.com 53 attempts, 41 addresses: tls-timeout 36, tcp-timeout 15, reset 1, refused 1 graph.microsoft.com 27 attempts, 6 addresses: http-301 27 login.microsoftonline.com 72 attempts, 20 addresses: http-302 72 teams.microsoft.com 18 attempts, 2 addresses: http-302 18

Second, in nine rounds, I asked DNS for every address of six Microsoft hosts and tried each address in turn: TCP, then TLS, then one plain request with no login. From 04:54 to 05:41 UTC, DNS gave me more than 40 different addresses for each of the three Outlook hosts, and not one of 186 attempts got as far as an HTTP reply. 138 took the TCP connection and then did not finish the TLS handshake within 6 seconds, 45 did not even open TCP within 6 seconds, 2 refused the connection and 1 reset it. Graph, Microsoft sign-in and Teams answered all 117 of their 117 attempts.

Grid of small squares, one per server address per round, for six hosts over 9 rounds. The three Outlook hosts are almost all TLS timeouts and none answered; Graph, sign-in and Teams answered every time

Each square is one address DNS returned for that host in one round. One home connection in India, so people elsewhere may have reached healthier servers.

What does that tell us? A server that accepts TCP but never answers the TLS hello is alive enough for its operating system to take the connection, but the program that should do the secure handshake is not getting to it. That is consistent with what Microsoft described at 01:06 UTC, though from outside I cannot see which machine stalled. It also means a load balancer that only checks whether TCP opens would still call these servers healthy.

Why an overloaded service can stay down after the first cause is fixed

The hardest line in Microsoft's updates is the one from 23:59 UTC: servers put back into service went down again once traffic reached them. One pattern that fits this is what researchers call a metastable failure: a system that stays broken on its own, even after whatever broke it has gone away. Microsoft has not said this is what happened, and its later updates suggest the trigger may still have been present.

In a metastable failure the first trigger, whatever it was, knocks capacity down. Then the system's own reactions keep it down. Users and apps retry, the retries add load, the overloaded servers waste time on requests that time out, and they complete less real work than before. Removing the trigger does not help, because the extra load is now coming from the outage itself.

To make this concrete I wrote a small model in Python. It is not Microsoft's system; the numbers are mine. One backend can serve 1,000 requests a second, users send 800, and every failed request is retried up to three times. Past its capacity the server wastes work on requests that time out, so it completes fewer of them as the load grows, which is how real overloaded servers behave. For one minute I cut capacity to 300, then restored it fully.

With plain retries the server never recovers in the 15 minutes the model runs. Up to four tries per request turn 800 requests a second into about 2,500, and the server serves only about 16% of them for good. With exponential backoff and jitter it is stuck at the same level in this model, because almost every request was failing, so the same number of retries still arrived, just spread out. Only when the front door also turns away everything above 900 requests a second, at once and cheaply, does the server catch up. It is back to serving everything 24 seconds after capacity returns.

Line chart of the share of requests served per second over 450 seconds. Retrying at once and backing off with jitter both stay stuck at 16 percent after the capacity cut; backing off plus blocking extra traffic at the front door recovers to 100 percent 24 seconds after the fix

In this toy model, only turning traffic away lets the server recover. Backoff alone did not help here because nearly every request was failing.

Backoff still matters. It stops retries from all arriving in the same second and gives a recovering server room. But backoff on its own is not guaranteed to bring the load under capacity. Something has to say no. That is load shedding: reject work early and cheaply, before the server spends effort on it, so the work it does accept finishes. Microsoft's step of limiting which traffic reached the affected servers, and bringing it back gradually, works the same way.

"When these factors are combined, an overload creates its own feedback loop that results in overload as a steady state."

Amazon Builders' Library, "Using load shedding to avoid overload"

How to design your own service so this does not take you down

You probably do not run anything as large as Exchange Online. But you almost certainly depend on something like it, and you run services that others depend on. These are the safeguards this outage argues for, in the order I would add them.

  1. Never let health checks remove most of your servers. Set a limit, for example: never take more than a third of a pool out of rotation because of failed checks. If more than that fails at once, the check or a shared dependency is the likely problem, not the servers. Some load balancers do this by failing open: below a minimum share of healthy servers they ignore the checks and use every server (Envoy calls it the panic threshold; AWS target groups have minimum healthy settings).
  2. Check the real path, but keep the check cheap. A check that only opens TCP would have called Microsoft's stuck servers healthy. A check that runs a full mailbox query will fail on busy servers and remove them. Test the step users need (here, completing the TLS handshake), and keep it light.
  3. Shed load at the front door. Give each server a limit on concurrent work and reject anything above it at once with a clear "try later" (HTTP 503 with Retry-After). A fast rejection costs little; a slow timeout costs a full request of work. If setting up connections is what overloads, as Microsoft described here, limit new connections at the edge before the TLS handshake, not after it.
  4. Cap retries in every client you own. Use exponential backoff with jitter, and a retry budget: stop retrying when, say, more than 10% of recent calls are already retries. Three retries at every layer of a deep call chain multiply load many times over.
  5. Bring capacity back slowly. When servers return, admit a small share of traffic first and raise it step by step. Every client reconnecting at once is a second outage. Microsoft did this in specific locations, starting with a narrower set of connections.
  6. Contain the blast radius in your own product. If your app reads mail or calendars through Microsoft Graph, decide now what the screen shows when that call fails: a cached copy, a short message, or the rest of the page without that panel.
  7. Freeze changes during an incident. Microsoft paused all deployments and configuration changes about three hours in. Make that an automatic step in your incident process, so nobody changes two things at once while you are still learning what broke.

What I could and could not check

Microsoft's updates are quoted from two places: its public status feeds at status.cloud.microsoft, which I saved every five minutes from 04:48 UTC on 13 November, and its Service Health record for EX1550543 and MO1550821, which the University of Pennsylvania's mail team republishes word for word with UTC times. I did not use news reports for any fact here. The probes are real but narrow: one home connection, six hosts, no login. The retry model is a model with numbers I chose, written to explain the mechanism, not to reproduce Microsoft's system. Microsoft's own explanation changed during the day, and its final report may change it again.

Read the full explainer

This article is adapted from the full explainer on System Design Academy, Microsoft 365 outage, 12 November 2026: why Outlook and Exchange went down, and what else broke, which has the complete timeline, the sources and the practical steps for users and admins, and which I update as Microsoft publishes more. If you want to learn how to design services that shed load instead of falling over, and recover once the cause is gone, the System Design course covers health checks, retry and backoff, load shedding, bulkheads, graceful degradation and incident management, each as its own lesson with diagrams and a quiz.