Microsoft 365 Outage: Lessons for SaaS Dependency Response

When a cloud provider has an outage, at least it shows up as errors in your own dashboards. When the vendor that runs your email, calendars and chat has one, it is harder to spot. Your systems stay green, people quietly stop receiving mail, and the first signal is usually someone asking in a hallway or a side chat whether Outlook is broken for everyone.

The Microsoft 365 outage that started on 12 November 2026 is a good case study. Exchange Online degraded, and with it every Microsoft 365 feature that reads mail, calendars or contacts. Below are the practical lessons for engineering and IT teams, taken from what actually happened and what Microsoft published. Microsoft's root cause is not out yet, so this is about response, not about blame.

1. You can check the wrong status feed

Microsoft runs separate status feeds for consumer and business services. At 18:32 UTC on 12 November its business-side post already said users "may be unable to connect to multiple Microsoft 365 services", with Exchange Online first on the list. Around the same time, the consumer feed listed every consumer service, Outlook.com included, as Operational.

Both were accurate for what they covered. Outlook.com is a consumer service and Exchange Online is the business mail platform. Someone who searched "is Outlook down", landed on the consumer view and saw green would have concluded that the problem was theirs. The next morning the consumer feed changed to a Service degradation whose text named Outlook.com as affected. Even then, the individual Outlook.com row in the same feed still read Operational.

The lesson is not that the status page is wrong. It is that "Outlook" means different products to different people, and a single green dot answers a narrower question than the one being asked. Know which product and which feed your organisation actually depends on before an incident, and watch the business and consumer feeds side by side. We made that easy on Pagerly's free status pages: the Outlook status page tracks Outlook.com and Exchange Online together, and the Microsoft 365 status page shows every service in one place.

We have written before about why vendor status pages are not an on-call signal on their own. This outage adds one more reason: even when the vendor posts quickly, you have to be reading the right post. (For the systems side, how failover and retries can overload a fleet, see when failover overloads the fleet.)

2. Measure the dependency from your side

The fastest signal for a mail outage is your own mail. A few cheap checks catch most of it before anyone opens a ticket:

• A synthetic round trip: every few minutes, send a message from an external mailbox to a monitored internal one and alert if it does not arrive within a threshold. Delayed delivery was one of the explicit symptoms in this incident.
• Graph and API error rates: if internal tools read mailboxes or calendars through Microsoft Graph, track their timeout rate. Microsoft said Graph requests touching Exchange data "may time out". Without that context, the errors look like a bug in your own integration.
• User reports as a signal: give people one obvious place to say "mail is broken", and treat a burst of those reports as an alert in its own right.

Vendor status then becomes confirmation, not detection. You already know something is wrong, and the status page tells you whether it is on your side or theirs.

3. Keep incident comms off the failing vendor

This outage hit the tools many teams use to run incidents. Microsoft listed Teams calendar features, meeting scheduling and invites, Live and Virtual event creation, and private and shared channel creation as failing, while chats, calls and standard channels kept working. Email itself was the main casualty.

Look at your own incident process and find each step that quietly assumes Microsoft 365 is up:

• alerts or pages delivered by email;
• an incident bridge created as a Teams meeting invite;
• on-call handoffs or rotations driven by an Outlook calendar;
• status updates to stakeholders sent as email.

Each one needs a fallback that does not share the same failure: SMS or phone paging, a standing bridge link, a chat channel that already exists, or a status page hosted elsewhere. The time to set those up is before the outage, not during it.

4. Declare an incident even when you can't fix it

Teams often skip declaring an incident for a vendor outage because nothing can be fixed internally. That is a mistake. An internal incident still does the useful parts: one owner, one channel, one source of truth for "what do we tell people".

Matching your update cadence to the vendor's helps. Microsoft's posts each carried a "Next update by" time, for example 20:30 UTC after the first post and 12:00 UTC on 13 November. Post your internal update right after each one: what Microsoft said, what it means for your users, and any workaround. Microsoft's own posts included workarounds worth relaying. Power Apps users could use the web version, and Fabric users could remove a sensitivity label if their policies allowed it.

5. Plan for the backlog, not just the outage

Microsoft extended its email timeout window to 48 hours so that delayed messages would be retried rather than bounced. That protects mail, but it also means a long tail: messages from the outage window can keep arriving hours after the incident is marked mitigated.

• Tell people not to resend. Duplicates add load to queues that are already behind.
• Expect stale alerts. Anything that pages by email may deliver old alerts late, so check timestamps before acting.
• Re-run anything time-sensitive that depends on mail or calendars: approval flows, ticket ingestion from shared mailboxes, scheduled reports.
• Keep the internal incident open until the backlog has cleared, not just until the vendor flips to green.

A short runbook for the next one

1. Confirm from your own signals: the synthetic mail check, Graph error rates and user reports.
2. Check the vendor's business and consumer feeds, and note the incident title and next update time.
3. Declare an internal incident and move communication to a channel that doesn't depend on the vendor.
4. Post an update after each vendor update, including any workarounds.
5. After mitigation, manage the backlog: no resends, check alert timestamps, re-run time-sensitive jobs.
6. When the vendor's Post-Incident Report lands, read it and update your dependency map.

You can't prevent a vendor's outage. You can make sure it doesn't also take out how you detect and talk about it.