Today, 13 November 2026, Microsoft went down.
For me the impact was small, someone tried to call me and couldn't get through. Others, couldn’t access their emails. More critical services stopped operating;
“We are currently unable to receive complaints, whistleblowing and malpractice submissions.” Ofqual (Guardian)
“Our Teams and Outlook are currently down. Our concerns are about patients who would usually contact us by email, some with very urgent needs and requirements.
“We are as best as possible informing them about the outage and to contact us by phone until further notice.” An administrator in a community NHS service in greater London (Guardian)
Some of our major services survive on very fragile infrastructure
Take the story of the Paul Eggert. Dubbed “The Time Zone King,” Paul Eggert is the editor and coordinator of the Time Zone Database, which is now part of the Internet Assigned Numbers Authority (IANA).
“If you’ve ever looked at the clock on a computer, smartphone, smartwatch or practically any other digital screen — and the time has been correct — you owe Eggert, a senior lecturer of computer science at the UCLA Samueli School of Engineering, a debt of gratitude. Working quietly in his spare time, Eggert helps manage everyone else’s time across the globe’s 24 plus time zones.” (UCLA)
It’s where the infamous XKCD cartoon came from, joking that all modern digital infrastructure relies on a lecturer in Nebraska. Like, literally, a guy in Nebraska managing time zones used across all modern technology.
Whenever a major service goes down we learn about the infrastructure and materials of it
A slide from my agile service design course on Service FailureWhenever a major service goes down I always think it's a tipping point. It's the moment the general public really starts to understand the infrastructure behind how a service gets delivered to them.
When services fail through complete outage, we uncover the materials of how they are made.
What is a service made of?
By materials, I mean what a service is actually made out of.
It’s technology stack, the data behind it, the infrastructure that support it to run. The people delivering the service and their autonomy, support, skills and training, laws, rules or policies, spaces, buildings and places. Most of what I describe in Full Stack Service Design. These are all materials things, and decisions that can be designed.
Most of the time, users never see any of this, and that's sort of the point.
Then something breaks, and suddenly everyone is an infrastructure expert or flagging what experts have been highlighting about critical infrastructure for a long time..
What's interesting with Microsoft is that lots of people are blaming Microsoft. Of course they're responsible, but Microsoft itself is pointing at other things in the stack of how its service gets delivered.
“No link has been made. Microsoft has not connected the Outlook and Teams outage that began Thursday to its job cuts, and none of its public updates on the outage mention staffing. The company has blamed servers that failed automated health checks and went offline,” (Nacionale)
Are you the front door for blame?
So the question for any organisation is: where in the chain are you? And when something further down that chain fails, will your customers come to you first?
Often the answer is yes. You're the name on the bill, the app on their phone, the number they know. You're the front door, whether or not it's your fault.
Energy companies are a good example of doing this well. When there's a large or medium power cut, many of them have an automatic post on their homepage.
It says: ‘We know there's an outage, often in your area.’
In the UK context it explains to you how your energy is delivered and then to contact the National grid. Diverting you to where to report or complain your issue.
That's not passing the buck. It's helping someone get to the right place quickly.
Some failures can't be designed out
It is inevitable that services will fail users.
Beyond a service not helping someone to do what they’re trying to do… even if that service is well designed, it is likely there will be some form of service failure. This can be from bad design, the service not being accessible or inclusive. But what is becoming a more common failure, is services failing because of a wider infrastructural/system coupling and subsequent outage.
Charles Perrow wrote about this in Normal Accidents. He argued that some accidents are unavoidable and cannot be designed around, when:
the system is complex
the system is tightly coupled
the system has catastrophic potential]
He argued that in some systems, accidents aren’t caused by one person’s mistake. They are a “normal” result of how the system is built. He judged systems on two things. Interactions asks whether the parts work in a predictable sequence (linear) or affect each other in hidden, unexpected ways (complex). Coupling asks whether a failure passes straight on with no slack (tight), or whether there’s time and room to recover (loose). His warning was that systems which are both complex and tightly coupled will eventually fail in ways nobody can foresee or stop in time.
Linear and tight: failures are easy to understand but spread quickly, so the system needs fixed procedures and central control. Examples include dams and rail transport.
Complex and tight: the danger zone. Failures are hard to understand and spread too fast to stop, so serious accidents are, in Perrow’s word, “normal”. Examples include nuclear plants and space missions.
Linear and loose: the most manageable. Problems are visible and there’s time to fix them. Most manufacturing sits here.
Complex and loose: surprises happen, but there’s slack, so people closest to the problem can adapt locally. Universities are his example.
Interpretation of Perrow’s (1999) model of complexity for servicesA few things I take from Perrow’s Model of Complexity (1999) quadrant for services today:
More of our services have drifted into the complex, tightly coupled corner. Lots of organisations sit on the same few cloud platforms, identity providers and payment systems. One failure ripples through thousands of services at once.
Complex means nobody holds the whole picture. Failures come from parts interacting in ways no single team planned for, so you can't fix it by tightening up your own bit.
Tightly coupled means there's no slack. When one part stops, everything after it stops too. There's no queue, no buffer and no manual workaround to fall back on.
You can't always reduce complexity, but you can sometimes loosen the coupling. A paper form, a phone line that doesn't depend on the same platform, a way to take an order and process it later. Slack isn't waste, it's resilience.
Some service failure is slow. This can either mean time to catch it with the right measurement and observation in place. Or some is more like a cliff edge, like a leak that keeps dripping until one day, the water pools and tips over.
Even if a failure is out of your hands, because the system is tightly coupled and you can't control it, you still need to be prepared to speak to and communicate with your users.
Services will always fail. It's how we design what happens when they do that matters.
What to do before your service fails
Think about service continuity before you need it:
Map your dependencies. What is your service made of, and who provides each part?
Find your weak spots. Where is it most likely to fail, and what happens to users when it does?
Work out who customers will blame. If one of your dependencies goes down, will people come to you? How will you signpost them to the right place, and how will you support them in the meantime?
Check your terms and conditions and policies, then be clear with users about what is your responsibility and what isn't. Just because you don't provide the whole service, doesn't mean you're not responsible for the outcome.
Explain what you're going to do about it. Say what has happened, in plain language, and explain the infrastructure if it helps people understand.
Set expectations, even if they're not time-based. You may not know when it will be fixed, but you can say how big a challenge it is.
Pre-empt the contact. Write the homepage banner, the status message and the call centre script now, not during the outage.
Climate Adapted Services. If you’re not thinking about one of the biggest future collapses, climate change, start preparing and adapting your services now.
Outages are when people learn what your service is made of. Better you are prepared for them to learn it from you.
I run a module on service failure as part of Agile Service Design at the School of Good Services. If this is something your team is thinking about, I’m running the course next year in 2027.