Relying on one cloud provider: what the Microsoft outage teaches about continuity
Email, calendar, files, sign-in, device management and security: at many organisations they all come together with a single provider. That is usually a sensible choice. But the Microsoft 365 outage of November 2026 shows what happens when the foundation falters. Here you can read how to map where you are dependent, and which measures are proportionate.
For most organisations, becoming fully independent is neither necessary nor feasible. It is worth knowing, though, which processes grind to a halt when a single service goes down, and having a fallback route for the most important ones.
Below you will find why a single outage has such a wide impact, how to map your dependencies and what reasonable measures look like. Status of the outage: Friday 13 November 2026, 10:15.
Why a single outage has such a wide impact
- In this outage, Exchange Online falters, and with it everything that depends on it: calendars, Copilot, parts of Defender, Intune and Purview.
- For most organisations, a large cloud platform is more reliable than anything they would run themselves.
- The risk lies not in the cloud, but in processes that nobody realises depend on a single service.
- For each critical process, map which service it needs and what you do if that service goes down.
- A fallback route doesn't have to be expensive: a phone list, an emergency channel or an export can be enough.
The outage started with Exchange Online, the email service of Microsoft 365. According to Microsoft, all features of other services that communicate with Exchange Online are affected, while components that don't keep working as normal (Microsoft status page). That sounds limited, but the list of affected components covers twenty services and components: from the calendar in Teams to Safe Links in Defender and device enrolment in Intune.
This isn't the fault of a single organisation or a single provider. It is the flip side of a well-integrated platform: services work together smoothly because they rely on the same components. As long as those components work, you notice nothing. When one fails, you only then discover how much depended on it.
How to map your dependencies
Don't start with the technology, but with your processes. Which five to ten things have to happen every day to keep your organisation running? Taking orders, making schedules, sending invoices, talking to customers. For each process, look at which services it uses, including the ones you don't immediately think of.
- Choose your critical processes
What has to happen today, even if there is an outage? Keep the list short.
- Trace each process through your systems
Where does the information come in, where is it processed, where does it go? Note every service along the way, including sign-in and email.
- Ask what happens during an outage
Does the process stop, slow down, or does nobody notice anything? Also look at integrations that run automatically.
- Decide how long it may take
Can it wait an afternoon, or is it already a problem after an hour? That determines how much effort a fallback route is worth.
Don't forget the software you have had custom-built or that a provider runs for you. Many custom systems send email, read calendars or sign users in via Microsoft 365. In this outage, according to Microsoft, requests via Microsoft Graph that needed to reach mail data also failed. What that means for integrations is covered in the article on integrations with Microsoft Graph.
Which measures are proportionate
After a major outage, the question comes up of whether you should switch to a second supplier. For most organisations, that is the answer to a different question. Two full office platforms side by side are expensive and make management more complex, and more complex management is a risk in itself. It is better to look at each critical process and ask what the smallest measure is that really solves the problem.
Measures from small to large
| Measure | What it solves | When it fits |
|---|---|---|
| Emergency channel and phone list outside Microsoft 365 | Employees and customers stay reachable | Always; this is the foundation |
| Runbook with a single point of contact | Calm and one consistent message during an outage | Always |
| Regular export of critical data | Customer lists and schedules remain accessible | If a process cannot wait an afternoon |
| Software that handles outages gracefully | Your own systems do not stall when Microsoft falters | If you have custom software that relies on Microsoft 365 |
| Critical data or processes on a second platform | Work continues during a prolonged outage | For processes that must never stand still |
Is it about a single critical process? Tick what applies to see which way to go.
A runbook is enough
A technical fallback route pays off
Tick above what applies to your process.
A runbook is enough: 0A technical fallback route pays off: 0
What you can expect from your supplier
In its SLA, Microsoft promises a minimum availability per month, with service credits if it is not met. That credit is a percentage of your monthly fee and does not cover consequential damage. Read more in the article on SLAs and compensation. So do not expect an SLA to compensate your losses, but see it as an incentive for the supplier.
More important is what a supplier does during and after an outage: how quickly and honestly it communicates, and whether a report on the cause follows. Microsoft has promised that report (Microsoft status page). Read it when it appears, and check whether the cause says anything about your own setup. How to limit lock-in in general is covered in the article on avoiding vendor lock-in. For the timeline of this outage, read the outage overview.
affected services and components in Microsoft's notice on Friday morning, 13 November.
the component where it began: Exchange Online, Microsoft 365's email service.
steps to map your dependencies for each critical process.
Frequently asked questions
On depending on a single cloud supplier and business continuity.
Is it risky to have everything with Microsoft 365?
For most organisations, a large cloud platform is more reliable than anything they would run themselves. The risk lies mainly in processes that nobody realises depend on a single service.
Should I switch to another supplier after this outage?
Usually not. Two full platforms side by side are expensive and make management more complex. It is better to look at each critical process and ask what the smallest measure is that solves the problem.
How do I map my dependencies?
Pick your critical processes, follow each process through your systems, ask what happens in an outage and decide how long it may last. Do not forget custom software and integrations.
What is a reasonable first measure?
An emergency channel and phone list outside Microsoft 365, plus a runbook with a single point of contact. That is quick to arrange and prevents a lot of damage.
Does Microsoft compensate my losses?
No. The SLA gives service credit as a percentage of the monthly fee for the affected service and does not cover consequential loss.
What should I do with Microsoft's report after the outage?
Read it when it appears and check whether the cause says anything about your own setup, for example which features you use and how your integrations cope with downtime.
Further reading
The Microsoft 365 outage
Timeline, cause and all affected services.
Read more PlaybookWhat to do as a company
Emergency communication and alternatives during the outage.
Read more IntegrationsIntegrations built on Microsoft Graph
What the outage does to software that relies on Microsoft 365.
Read moreWant to know which processes depend on a single supplier?
Appfront builds custom software and helps organisations with resilience and continuity. Want to map your dependencies and build fallback routes that are proportionate? Book a conversation with a developer.