Outlook, Exchange Online, Teams, SharePoint, Copilot and Defender XDR went down worldwide on the afternoon of November 12. Microsoft says servers are failing health checks and overloading the rest. What we know, what happens to email sent to you in the meantime, and what to check once it is back.
At 1:26 PM ET on Thursday, November 12, Microsoft opened incident MO1550821: users may be unable to connect to Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot and Microsoft Defender XDR. Downdetector had more than 130,000 Outlook reports within the hour, plus tens of thousands more for Microsoft 365 and Teams. Microsoft later added Planner, To Do, Intune, Defender for Office 365, several Purview services, part of Power BI and parts of the Microsoft 365 Apps admin center to the list.
It was the second incident of the day. From 9:45 to 10:53 AM ET, a separate Teams incident (TM1550488) delayed messages and failed to load chats, which Microsoft put down to resource contention and marked resolved.
Microsoft first described "elevated load across multiple regions." It then corrected that: the load is "not driven by an increase in traffic, but by a number of servers being unexpectedly unavailable; straining the remaining infrastructure." Affected servers were failing automated health checks and being taken out of service, which pushed their share of connections onto the servers still standing. Microsoft later said a core process on the affected servers was becoming overwhelmed and causing them to stop responding.
That shape is worth knowing because it is common. A health check that removes a struggling server is meant to protect users. When many servers struggle at once, removing them concentrates the load on fewer machines, those start failing the same check, and the fleet shrinks itself. Recovery then means bringing servers back slowly enough that the returning traffic does not knock them over again, which is why outages like this one recover gradually rather than all at once.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Paused all deployments.
Redistributed connection traffic across its wider worldwide infrastructure.
Restarted and validated affected servers, and looked at reverting a small number of recent configuration changes.
Validated a different health-check method that returned some servers to service, and began applying it more widely along with automation to find and restart unresponsive servers.
Around 6 PM ET: a portion of servers returned and stable, traffic shifted to alternate routes where possible, and "limited recovery" observed. Microsoft said users would see a gradual recovery as their apps reconnect.
At 7:06 PM ET: the returned servers "can become unresponsive again once they receive traffic." Microsoft began analyzing what triggers it and temporarily limited which types of traffic can reach the affected infrastructure.
At 8:59 PM ET: "positive results" from restarting affected infrastructure in an isolated manner, with Microsoft monitoring those servers for stability before relying on them.
Microsoft has not said this was an attack, and nothing it has published points to one. Amazon said AWS services were operating normally and disputed reports that it was also affected.
Usually not. Email between organizations is delivered by the sender's mail server, and when the receiving server is unreachable the sender keeps the message and tries again. The email standard (RFC 5321) asks senders to retry for at least four to five days before giving up, at intervals of half an hour or more. Most large providers follow it. Mail sent to you during the outage should arrive late, in a burst, once Exchange Online is accepting connections again.
Mail you tried to send from Outlook during the outage may still be sitting in your Outbox. Check it once you are reconnected.
Small or custom senders (a contact form, a monitoring tool, an app sending its own mail) may retry for far less time than the standard asks. If something important was due today, ask for it again.
Do not change your MX records to "fix" this. Senders cache DNS, a half-propagated change splits your mail between two places, and the outage is likely to end before the change settles.
Watch the Service health page in the Microsoft 365 admin center (incident MO1550821) and @MSFT365Status on X. If you cannot reach the admin center, the X account is where Microsoft posts first.
Tell your people where to talk in the meantime: a phone tree, a text group, whatever already exists. Do not make them each find out separately.
If your security team relies on Defender XDR, it is affected too. Note the window, because alerts raised during it may arrive late or need a manual look afterwards.
Restart Outlook and Teams once Microsoft reports recovery. Clients that kept retrying can sit in a bad state after the service is back.
If your own application sends mail through Exchange Online (SMTP AUTH, a connector, or the Graph sendMail API), today those sends failed. Whether anything was lost depends on whether your code queued the message and retried, or gave up after one attempt and logged an error nobody reads. The same goes for anything that reads a shared mailbox, posts to a Teams channel, or pulls files from SharePoint.
Put outgoing mail on a queue with retries, so a provider outage delays messages instead of dropping them.
Make the retry safe to repeat, so a message that half-sent does not go out twice.
Know which of your features stop working when Microsoft 365 is down, and say so on your own status page rather than letting customers discover it.
Add up your dependencies. An app that needs five services each at 99.9% is not itself at 99.9%.
Full restoration, the final impact window, and Microsoft's post-incident review, which Microsoft publishes in the admin center after an incident of this size and which names the root cause more precisely than live status posts can. We will update this report when Microsoft publishes it.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Law Firm Security in 2026: What Clients' Outside Counsel Guidelines Ask For, and How to Answer
Corporate clients increasingly send outside counsel guidelines and security questionnaires before engaging a firm. The requests are predictable: MFA, encryption, incident notification, data return and destruction at matter end, vendor controls. The ethical baseline (Model Rule 1.6(c) and ABA Opinion 483), the common asks, and how mid-sized firms meet them without an enterprise security team.
Read
SEC Regulation S-P Amendments Now Apply to Everyone: Incident Response, 30-Day Notices and Vendor Oversight
Larger broker-dealers, investment advisers, investment companies and transfer agents had to comply with the amended Regulation S-P from December 3, 2025; smaller ones from June 3, 2026. Every covered firm now needs a written incident response program, notice to affected individuals within 30 days, and oversight of service providers. What changed and how to make it work on AWS.
Read
As of November 12, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.