A widespread Microsoft 365 outage disrupted Outlook, Exchange Online, Teams and Copilot. Microsoft traced it to servers failing health checks, ruled out malicious activity, and promised a post-incident report.cidents EX1550543 and MO1550821. The company pointed to overwhelmed connection-establishment processes, failing automated health checks, and elevated processor usage on the affected hosts, and said it was rolling back a recent network configuration change. Microsoft has stated it found no evidence of malicious activity, and its service advisories have not tied the disruption to CVE-2026-124194, an exploited Outlook spoofing flaw patched two days earlier.

What broke, and where

The disruption began Thursday and carried into Friday, degrading Microsoft 365 in several regions. Microsoft's first customer-facing reports described connection problems for Exchange Online mailbox users in the Americas. The scope widened as telemetry came in: Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR, and a long list of other workloads were flagged as potentially affected.

The dependency structure matters more than the raw service list. Microsoft said any feature in those services that needs to talk to Exchange Online or the email stack was hit, while functionality that does not depend on that interaction kept working. That pattern — broad-looking impact tracing back to one shared dependency — is typical when a high-traffic backend degrades.

Some Google Workspace (formerly G Suite) users also reported that they could not reach their Google-hosted mail through Outlook desktop and mobile clients, which fits the same failure surface: the Outlook client path, not the mailbox provider.

Microsoft's load explanation was that a large number of servers had become unavailable, pushing the traffic those machines would normally absorb onto the surviving fleet. Total traffic volumes had not risen, the company said — the capacity to serve it had shrunk.

Timeline of Microsoft's updates

  • Thursday: Exchange Online mailbox connectivity problems reported for users in the Americas; the scope later expanded to Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR, and other services.
  • Shortly before 3 p.m. ET: Microsoft reported that affected servers were failing automated health checks. It was testing a workaround that skips the component responsible for processing those checks, and was separately investigating elevated processor usage on the impacted machines.
  • November 12, 9:00 p.m. ET: Restarting affected servers was producing signs of improvement, though Microsoft was still watching for stability and had not confirmed full recovery. The company disclosed that a process handling secure connection establishment was becoming overwhelmed, which caused servers to stop servicing requests. It began reversing a recent network configuration change that lined up with the onset of the incident and was monitoring whether that rollback helped.
  • Friday: Microsoft said there was no indication of a malicious attack.

Throughout, both the Exchange Online incident (EX1550543) and the wider Microsoft 365 incident (MO1550821) stayed open in the service health dashboard. Just before 3 p.m. ET, both were classified as service degradations. Customers can follow them in the Microsoft 365 admin center.

Was this a cyberattack?

At publication time, Microsoft was still working out what triggered the failures and had disclosed no evidence of an attack. The Friday update went further:

"At this time, we have no evidence of malicious activity associated with this incident. We will continue to treat this with urgency until full mitigation, and we will share a full Post-Incident Report with root cause and defense-in-depth actions after mitigation is complete."

That post-incident report is the document to watch. Until it lands, the root cause is unconfirmed. The observable facts — health probes failing, a connection-handling component saturating, CPU elevated, a coincident network configuration change — are consistent with an operational fault, but Microsoft has not finalized the causal chain.

The Patch Tuesday coincidence

The outage landed two days after Microsoft shipped its November Patch Tuesday release, which fixed 1,094 vulnerabilities across its products. One of them, CVE-2026-124194, is an Outlook spoofing flaw that Microsoft says has been exploited in the wild. Per Microsoft, opening a specially crafted file in an affected Outlook client can expose the user's authentication material.

There is no established link between that vulnerability and the Exchange Online disruption. Microsoft's service advisories do not connect the two, and nothing in the published updates suggests exploitation drove the server failures. Treat any claim that CVE-2026-124194 caused the outage as unsupported. The overlap in timing is a coincidence until Microsoft says otherwise.

Technical background

The failure modes Microsoft described belong to a well-understood class of cloud availability incidents, and understanding them helps admins interpret the status updates.

Health checks as a failure amplifier. Load balancers and orchestration layers route traffic only to instances that pass automated probes — typically an HTTP endpoint, a TCP port check, or a synthetic transaction. If the component that evaluates those probes is itself degraded, healthy servers get marked unhealthy and pulled from rotation. The result is a shrinking pool serving the same demand, which raises load on the survivors and can cascade. Microsoft's workaround — bypassing the component that processes the checks — targets exactly this loop.

Connection establishment as a bottleneck. Before a request is served, a session must be set up: TCP handshake, then TLS negotiation. Under high connection churn, the work of terminating TLS (key exchange, certificate operations, session resumption) can consume more CPU than the application traffic itself. When that path saturates, servers stop accepting new requests even though the application process is fine — matching Microsoft's description of an overwhelmed secure-connection process.

Generic checks admins can run against any endpoint to separate these layers, substituting their own hostnames:


# Is the TCP port reachable, and how long does the handshake take?
time curl -sS -o /dev/null -w 'connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n' \
  https://<exchange-endpoint>/

# Inspect the TLS handshake directly, including certificate chain and negotiated protocol
openssl s_client -connect <exchange-endpoint>:443 -servername <exchange-endpoint> </dev/null

On Windows, the equivalent reachability test for the client-to-service path:


Test-NetConnection -ComputerName <exchange-endpoint> -Port 443

Config changes and rollback. A network configuration change that coincides with the start of an incident is the first thing most responders revert, because reverting is cheap and produces a clean signal. A successful rollback does not by itself prove causation, and Microsoft has framed the rollback as something it was monitoring, not as a confirmed fix.

Detection and mitigation while the incident is open

  • Watch the incident IDs, not just the service name. EX1550543 covers Exchange Online; MO1550821 covers the broader Microsoft 365 impact. Feature-level status can differ inside a single degraded service, particularly for anything that calls into Exchange Online.
  • Test the dependent path explicitly. If mail-adjacent features misbehave while other workloads are fine, verify whether the failure is in the service or in the client's route to it, using the reachability checks above.
  • Expect client-side symptoms from third-party mail. Google Workspace users hitting Google-hosted mail through Outlook desktop and mobile clients were affected by the same Outlook-side problem, so a working webmail session is not evidence that the Outlook path is healthy.
  • Do not attribute the outage to CVE-2026-124194 without evidence. Patch status and service health are separate questions. Apply the November updates on their own merits, and track the post-incident report for the actual root cause and the defense-in-depth actions Microsoft commits to.

Microsoft has said it will keep treating the incident with urgency until full mitigation and will publish that report afterward. For now, the confirmed facts are the failing health checks, the saturated connection handling, the elevated CPU, the rolled-back network change, and the absence of any evidence of malicious activity.