Microsoft 365 Outage: What EX1550543 Means for Developers

A single network configuration change during a routine capacity upgrade took Exchange Online offline at 16:17 UTC on November 12. By the time Microsoft contained the damage—19 hours later—Outlook, Teams, SharePoint, Copilot, Defender XDR, and Intune were affected across 74 countries. If you have any code that calls Microsoft Graph, runs Exchange connectors, or depends on Copilot agents, this was your problem too. Here’s what actually happened and what you need to fix before the next one.

What Happened: A Health Check Killed the Pool

The cascade worked like this. After a network config change, Exchange Online servers began failing automated health checks. The cloud orchestration layer did exactly what it’s designed to do: it pulled failing servers out of rotation. That’s the correct behavior. The problem is what happens next.

The surviving servers absorbed the redirected traffic, became overwhelmed, and started failing their own health checks. Those servers got pulled too. Each removal increased load on whatever remained, triggering a feedback loop that chewed through capacity across regions. This is incident ID EX1550543—tracked separately from the broader MO1550821 that opened two hours later when 18 downstream services started failing.

Microsoft confirmed this was not a cyberattack and not AI-related. Resolution required staged server restarts, an alternative health-check method, a network config rollback, and traffic rerouting. The 48-hour email retry window Microsoft opened suggests some queued messages needed redelivery after the fix.

The same failure mode—health check triggers pull, pull triggers overload, overload triggers more failures—has shown up in prior major cloud incidents. It’s a property of auto-healing cloud infrastructure, not a one-time bug.

What Broke for Developers (It Wasn’t Just Email)

Everything that reads from Exchange Online was in scope. That’s a larger surface than most developers expect:

• Microsoft Graph API endpoints for mail, calendar, and contacts returned timeouts
• Exchange Online connectors in Logic Apps and Power Automate stopped executing
• Copilot Chat failed to load and could not reach email or calendar data
• OpenAI and Anthropic M365 connectors both went offline
• Custom REST integrations reading Exchange via the API queued or silently failed

Three years ago an Exchange outage meant slow email. In 2026, it means AI agents that read your calendar, approve pull requests via Teams, or trigger workflows from inbound email are down. Microsoft made Exchange Online a runtime dependency for autonomous systems. This outage is the first major test of what that dependency costs.

What to Add to Your Graph Code Now

The official Microsoft Graph SDKs for .NET, Python, and JavaScript include a RetryHandler that reads the Retry-After response header and backs off automatically. If you used the SDK, you got retry behavior for free. If you wrote a custom HTTP client against the Graph API, you do not get this. You need to add it.

import time, random

def call_graph_with_retry(fn, max_attempts=5):
    for attempt in range(max_attempts):
        resp = fn()
        if resp.status_code == 503:
            retry_after = resp.headers.get("Retry-After")
            wait = int(retry_after) if retry_after else min(2**attempt + random.uniform(0, 1), 60)
            time.sleep(wait)
            continue
        return resp
    raise Exception("Graph API unavailable after retries")

Three other things worth adding regardless of SDK usage:

1. Surface degraded mode when 503 ServiceUnavailable patterns persist for more than 60 seconds—don’t silently queue failures
2. Log correlation IDs from every Graph response header—these are required when escalating a support ticket
3. Identify your email-gated flows—approvals, regulatory notifications, SLA triggers—and assign a human fallback path for each

An agent workflow that assumes email always works will silently fail during the next Exchange outage. That’s a worse outcome than a loud failure.

SLA Credits: Claim Before December 31

Microsoft’s 99.9% monthly uptime SLA for business subscriptions triggers credit tiers when that threshold breaks. At 19+ hours in a 720-hour month, downtime was approximately 2.6%—well below the 99.9% threshold. The credit tiers are 25% for below 99.9%, 50% for below 99%, and 100% for below 95%.

Microsoft does not apply these automatically. To claim:

1. Go to the Microsoft 365 admin center
2. Open a Service Request and request an SLA credit review
3. Cite EX1550543 (Exchange Online) or MO1550821 (broader M365)
4. Include duration, affected services, and affected user count

If you purchased through a Cloud Solution Provider or reseller, your provider must file on your behalf. The deadline for November incidents is December 31, 2026.

The Bigger Point

When Exchange goes down and it takes Copilot agents, AI connectors from two major AI providers, and 18 M365 services with it, the risk profile of a single-vendor dependency has quietly changed. This is worth treating like any external API: assume it fails, build circuit breakers, test your fallbacks before you need them. The post-incident review Microsoft has promised will likely show how the network change got approved without catching the health check risk. That’s a process problem on Microsoft’s side. The resilience problem is yours to solve.