Microsoft 365 Went Down for Nearly 24 Hours. Here Is What Microsoft Has Actually Said.

On 2026-11-12, Microsoft 365 broke. For close to 24 hours, Outlook, Teams, Copilot and more were disrupted for users in dozens of countries.

I want to write about it the careful way. Outages like this attract speculation within minutes: a cyberattack, an AI agent gone wrong, a bad patch. Most of it turns out to be noise. So this post sticks to what Microsoft has said, marks what is still unknown, and then gives my view on what developers should take from it.

Sourcing, upfront:

• Microsoft hasn't published a blog post about this incident that I could find. Its updates came through the Microsoft 365 admin center, its public status page, and posts on X.
• The Microsoft statements quoted here come from news outlets that reproduced them, not from Microsoft's own pages. Those outlets are linked throughout and listed at the end.
• Microsoft has promised a post-incident report. As of 2026-11-14, it hasn't been published in any source I checked.

What happened

Microsoft tracked the problem under two incidents: EX1550543 for Exchange Online, and MO1550821 for everything that depends on it.

Here is the sequence, in UTC:

A few details matter:

• The first public acknowledgment was about Exchange Online mailbox access in the Americas, and a follow-up warned it could affect any region.
• Hours earlier, a separate Teams incident (TM1550488) had affected the Americas. Microsoft's records treat it as separate.
• Downdetector logged nearly 140,000 Outlook reports globally at peak. Remember these are user reports, not a count of affected users.

What Microsoft says caused it

On 2026-11-13, Microsoft apologized and gave its first plain account of the cause. In short:

• It said the incident originated in a problem during an earlier network capacity upgrade, which surfaced after a more recent network change.
• It said the issue was a technical issue not related to cyber or AI / agents, and that it had addressed the underlying issue.
• It said it restored service gradually, validating stability at each stage, which took longer but aimed for a stable restoration.
• It promised a full post-incident report once its review is complete.

Along the way, Microsoft's service-health updates described the mechanism it was seeing:

• A core process on the affected servers was becoming overwhelmed, which made the servers stop responding and drained capacity.
• A process that establishes secure connections was named as the source in a later update.

How the story changed during the day

This part is worth noticing, because early explanations are often wrong, and Microsoft's changed.

1. First hypothesis: elevated load. The early update pointed at a portion of infrastructure under high load across multiple regions.
2. Correction within about an hour. Microsoft said the load was not driven by more traffic but by a large number of servers being unexpectedly unavailable, shifting load onto the remaining ones.
3. "No recent change correlated." On 2026-11-12, Microsoft said it had not identified any recent change correlated with the start of impact, while pointing at a component that processes server health.
4. Next day: an earlier upgrade plus a recent change. The cause statement then tied it to an earlier capacity upgrade that surfaced after a recent network change.

These aren't necessarily contradictory. A latent flaw from an earlier upgrade could stay hidden until a later change exposes it. But the post-incident report should reconcile them, and I'd read it closely when it arrives.

What we still don't know

Honest list, as of 2026-11-14:

• What the flaw from the earlier upgrade was, and what the recent network change was.
• Why servers failed their automated health checks, and why returned servers became unresponsive again under traffic.
• Whether Azure workloads were affected. Azure's status page showed no active events, and Microsoft hadn't confirmed impact on customer-hosted Azure workloads at the time that source was written. Downdetector chatter about Azure is user reports, not confirmation.
• The official scale. I found no Microsoft figure for affected users or total duration beyond its status updates.
• Whether the incident has been formally declared resolved. Microsoft reported broad recovery. I did not find a formal resolution notice.

Who felt it

The effects went well beyond office email:

• The US House of Representatives' communications department said it was affected. Baltimore County's government said staff couldn't send or receive email, and that 911 and other essential services weren't affected.
• In the UK, a government spokesperson said it was working closely with Microsoft to assess impact. Some police forces told people to call 101 for time-critical, non-emergency reports.

It also wasn't Microsoft's first big Microsoft 365 incident this year. The Register reported a roughly 10-hour Microsoft 365 outage in January.

What developers should take from it

This is my view, not a claim about Microsoft's internals. The post-incident report may change the details. But several lessons hold regardless.

1. Health checks are code that can take you down

Microsoft's own updates describe servers failing automated health checks, dropping out, and pushing load onto the rest. I can't say that was the root cause, and Microsoft hasn't either. But the pattern is well known: automated remediation that removes unhealthy instances can accelerate a failure if too many go at once.

Questions worth asking about your own systems: What happens if every instance fails a check at the same time? Is there a cap on how many can be removed at once? Can an operator turn automatic removal off during an incident? I've written about health checks on this blog before, and the answer to the last question is usually "not as easily as we'd like."

2. Your communication channel can't depend on the thing that's down

For a stretch of the incident, Microsoft's own status page wasn't loading, and updates went out on X instead. Admins who couldn't reach the admin center needed another route. Publish status from infrastructure that doesn't share fate with your product, and tell customers where to look before the outage happens.

3. Recovery has its own failure mode

Microsoft said it restored services gradually, validating at each stage, because of the scale of demand. And it extended Outlook's email timeout window to 48 hours so delayed messages wouldn't be lost. Both reflect something every team learns eventually: when a system comes back, a backlog and a wave of reconnecting clients arrive with it. Design for the second spike, not just the first failure.

4. Know what you can't do without email

One expert quoted by TechRadar argued that a second service for resilience is easy to recommend and almost impossible to adopt in practice, because tools differ and few systems work with both. That's a fair point. You probably can't replace Microsoft 365 overnight.

What you can do is map your dependencies. Which of your processes silently require email? Password resets, approvals, alerts, customer replies. Which of those are time-critical? Write the manual fallback down before you need it, such as a phone tree or a second alert channel. The UK police advice to call 101 is exactly this: a pre-agreed fallback for the thing that matters.

This is the same lesson as the model-suspension post I wrote recently. Dependence you haven't mapped is risk you haven't priced. The vendor is different. The principle isn't.

5. Don't speculate. Wait for the report.

Microsoft felt it needed to say this wasn't caused by cyber activity or AI and agents. That tells you how fast the rumors moved. TechRadar also warned that phishing messages tend to appear while services come back, so be careful with password-reset prompts during recovery.

For engineers, the discipline is the one we apply to incidents of our own: say what is confirmed, say what isn't, and hold the root cause until the evidence is in.

If you're a business customer

One practical point: Windows Latest reports that affected business customers may be eligible for a service credit, but may need to ask Microsoft to review the outage. Eligibility depends on the service affected and your agreement. Check your own terms before assuming either way. This isn't legal or contractual advice.

The short version

A latent problem, a network change, and a fleet of servers that stopped responding took down email for two workdays. Microsoft says it wasn't an attack and wasn't AI. The report that explains the rest isn't out yet.

When it arrives, read it. And in the meantime, write down what your business does when email is gone.

---

Sources

• Al Jazeera: Microsoft hit by global outages
• TechRadar: Microsoft outage live blog
• CNN: Microsoft says email service is approaching normal levels
• ABC News: Outlook outage updates
• Windows Central: Microsoft apologizes for major outage
• BetaNews: Microsoft says network upgrade caused Microsoft 365 outage
• CIO: Microsoft struggles to get M365 services back online
• TIME: Microsoft struggles to repair worldwide outage
• SOCRadar: Microsoft Outlook outage summary
• Control Plane: What caused the Microsoft 365 outage
• Windows Latest: Microsoft insists it was a network upgrade
• The Register: January 2026 Microsoft 365 outage
• Microsoft's own channels, as relayed by the outlets above: the Microsoft 365 admin center (incidents EX1550543 and MO1550821), the public status page at status.cloud.microsoft, and the @MSFT365Status and @Microsoft accounts on X.