The 0.1% Problem: What the Microsoft Outage Tells Us About Digital Sovereignty

Outages happen at Microsoft, Google, and AWS, and they happen on servers we run ourselves. Anyone who’s worked in this business for a while has broken something in production. I have, too.

Microsoft 365 is a good product, and there are solid reasons so many companies use it. I don’t want to argue about whether systems fail. They do. What I’m interested in is what an outage means for you, and how much control you have over it.

Microsoft’s service level agreement for Microsoft 365promises 99.9% availability per service and month. If it’s less, customers get a service credit, but not the lost working day back. And when an outage happens, it hits every customer at the same time.

When thousands of organizations run email, chat, files, calendars, and their AI assistant on one platform, a single failure affects all of them together, with the same cause and no workaround.

Security researcher Dennis-Kenji Kipker said in the coverage after the outage that depending on a few cloud providers is a risk in itself, and that companies need redundancy and independent alternatives. Edgar Weippl from SBA Research pointed to lock-in: when prices go up and there are hardly any alternatives, switching becomes the risky option.

I find Weippl’s point the more important one. An outage is over after a day. Lock-in can shape your IT decisions for a decade.

“Digital sovereignty” is used a lot right now, and the term is getting worn out. For us it comes down to a simple question: can you still decide? Where your data lives, who has access to it, what you do when your provider changes prices or terms, and whether you can switch without starting from scratch.

The outage is the most visible part of that. There are others:

• Jurisdiction: Microsoft representatives told the French Senate that they can’t guarantee data won’t be handed to US authorities if US law requires it. That follows from US law, and you have to plan for it.
• Access controlled by others: In 2025, it was widely reported that the chief prosecutor of the International Criminal Court lost access to his Microsoft email after US sanctions, which Microsoft disputes.
• Concentration: If email, files, collaboration, identity, and AI all come from one vendor, each of them makes it harder to leave.

You don’t have to replace Microsoft 365 tomorrow. But you should know which parts of your organization would stop if one vendor stopped, and whether that was a deliberate decision.

Yes, it does. Running your own infrastructure isn’t automatically more reliable. It’s more work, and done badly, it’s less reliable than a hyperscaler. Open source isn’t free of cost, and sovereignty needs effort.

The difference is in how things fail:

• The outage stays with you. It affects your system, not half the world at once. Your team can see what’s happening and fix it, instead of waiting for a status page to update.
• You can switch. With open standards and open source, you can change your hosting provider, your agency, or your setup and keep your data and processes.
• You control changes. Nobody rolls out a network change to your production setup without you knowing about it.

Your own systems will fail sometimes, too. But you can act, and you can leave.

One of our clients runs course registrations through their TYPO3 website. Every registration triggers emails: a confirmation to the participant and a notification to the client’s team, which lands in a Microsoft 365 mailbox. The emails are sent through Microsoft 365, so this setup was directly affected.

A few months ago, we added our Mail Queue module to the system. TYPO3 still tries to send each email right away. Only if that fails does the email go into the queue, where it waits and is sent again later.

During the outage, that made a real difference:

• No email was lost. Everything arrived, some of it with a delay.
• The team could see what was missing. The TYPO3 backend showed at any time which registrations hadn’t reached the client’s own mailbox yet.
• Urgent cases didn’t have to wait. Some registrations needed to be handled right away, and a delivery after the weekend would have been a problem. We rerouted those so the team could work on them without waiting for Microsoft.

The client’s emails still went through Microsoft 365, and we didn’t change that. What changed was that the outage wasn’t a black box anymore. The team knew what was stuck, nothing disappeared, and they could decide for themselves which cases couldn’t wait.

Mail Queue is a small module, and setting it up wasn’t a migration project. Still, it meant the client kept control over their own data and processes while a service they rely on was down.

We’re a TYPO3 agency, so here’s how this looks in our area.

Your website is one of your most important digital assets: storefront, newsroom, and often service desk. It’s also one of the easier places to stay independent:

• TYPO3 is open source and has been for more than 25 years. No license fees, no vendor changing the terms, a public roadmap, and long-term support releases you can plan with.
• You choose where it runs: on your own servers, with a German or European hosting partner, or in the cloud, and you can move between them.
• Your content stays yours, in a standard database you can export, not in a proprietary format.

We call our way of working “core-near”: we stay close to what TYPO3 itself provides, avoid unnecessary third-party dependencies, and build things that still run in six years. That also keeps you independent at the level of a single extension.

To be fair, an independent website won’t keep Outlook running. But as the course registrations show, it can make sure your own processes keep working and nothing gets lost while someone else’s service is down. The same approach of open standards, real exit options, and fewer single points of failure also works for email, collaboration, and search. Public institutions in Germany are already going this way, for example with openDesk or Schleswig-Holstein’s move to open source workplace software.

Microsoft will fix this, publish a post-incident report, and in a few weeks most people won’t think about it anymore. That’s why I’d use the next few days:

1. List your single points of failure. Which tools would stop your organization if one vendor were down for a day?
2. Check your exit options. Could you leave each of them within a reasonable time, with your data, in an open format?
3. Check what your website does when email fails. Are form submissions, registrations, or orders lost, or are they queued and visible somewhere?
4. Start with what’s easiest. You don’t need a big migration. Your website, intranet, or search are good places to begin.

You don’t have to build everything yourself. But when the next outage comes, you should be the one deciding what happens next.