Single points of failure we chose ourselves
The Microsoft outage showed how many companies share one failure domain. Design your cloud, SaaS and network the way you design a network: no single point of failure.
On Thursday November 12, just after 17:00 CET, Outlook stopped working. Teams calendars failed, Copilot could no longer reach mail or files. A firm in Taiwan went back to trades by fax (yes, seriously). When the platform everyone depends on goes down, the fallback is whatever happens to still work.
One failure domain for everyone
A few hyperscalers host a large share of the world’s workloads, and a few SaaS apps run most offices. That happened for good reasons. (and nobody gets fired for choosing Microsoft 365 or AWS).
The side effect is that thousands of unrelated companies now share a single failure domain. When one control plane or region has a bad day, whole industries slow down at once. AWS showed it in October 2025, Cloudflare as well last year, and Microsoft this week.
Scale makes outages rare, but big
The engineers at these companies are excellent, and they run more automation than any enterprise. On a bad day, that amplifies issues. From what Microsoft has shared so far, servers became unavailable, traffic landed on the remaining resources, and those overloaded. Anyone who has seen a flapping spanning-tree network knows that cascade.
You cannot fix that from the outside, and no provider can promise it will never happen. What you control is the impact on your own business. AI makes that more urgent. As we connect agents to the mail, calendars, and files of a single vendor.
Design it like a network
One rule never changed in designing networks: no single point of failure. You design 2 routers, 2 uplinks, 2 physical paths, and a failover you actually test.
That is why it feels strange to see companies put their email, identity, collaboration, and AI assistant in a single tenant, at a single vendor, often in a single cloud region. In network terms, that is a single-homed site. Nobody would sign off on that for a critical location. Yet we accept it for the tools the entire company runs on.
Spread your bets
Moving everything off AWS or Azure is not realistic, and for most workloads, not necessary. The real question is which services you cannot afford to lose for a day, and whether they all need to live in the same place.
The alternatives have grown up. Neoclouds, built for GPU and AI workloads, are becoming serious platforms. Regional and national providers offer solid compute and storage, with data sovereignty as a bonus. And there is value in a provider where you know someone: when something breaks, you get an engineer on the phone instead of a status page. Keep your primary platform, make critical services portable with containers and infrastructure as code, and treat the second provider like a second uplink.
Question your SaaS
SaaS is harder, because you do not control the platform at all. But do we need this platform for this job? AI has changed the build-or-buy equation, and a focused internal tool now takes days to build. That does not mean replacing your email with something homegrown. It does mean your order intake or support workflow does not have to live inside the same vendor as everything else.
For the platforms you keep, plan the bad day in advance. Try to have a fallback channel before you need it.
Don’t forget the network underneath
None of this helps if you cannot reach your cloud and SaaS in the first place. Use two independent paths and providers for every site that matters, on physically different routes. Add 5G or LEO satellite as backup, and check that routing fails over when it should. (This is what we work on every day at GNX, and we are quite good at it.)
Resilience is a design choice
Global outages like this will happen again, and the platforms will only become more central as AI agents move into every workflow. So ask yourself: where are our single points of failure, and which of them did we choose ourselves? A fax machine in the corner is not a strategy.