Transcript
Use with ChatGPT / Claude Auto-scroll A
Introduces the Microsoft outage and shows how it quickly affected organizations across many countries. Explains that the problem began with email and spread because so many services depend on the same underlying systems.
On Thursday, one company had a problem, and within an hour, people in 74 countries were feeling it.Trains in Germany couldn't send out their timetables.New Zealand stopped processing visas.A hospital in Toronto declared a code grey.A court in Australia couldn't open its own case files.Nobody hacked anything, no cable was cut, no building caught fire.Microsoft's emails simply stopped answering.And when engineers switched the broken servers back on, they looked healthy and then fell over again.That's the part that should make you curious, because the reason this outage spread so far is the same reason it was so hard to fix, and it's built into almost everything you use online.This is the world backstage.Let's go behind the outage.
It started on Thursday around lunchtime on the US East Coast.In Australia and New Zealand, it was the early hours of Friday, so a lot of people there simply woke up to it.At first, it looked like an email problem.Outlook wouldn't load, messages wouldn't send.On Down Detector, the website people use to report outages, complaints about Outlook shot up to more than 2,000 times their normal level.And Down Detector only counts the people who bother to report.For every one of them, there were many more just refreshing their inbox, wondering if it was them.To understand why this mattered so much, you need to see what Microsoft actually is, because for most organizations, it isn't just one app, it's the office.Picture a normal company.Outlook carries its email, Teams carries its chats, its calls, and its meetings.SharePoint and OneDrive hold its documents.
The calendar decides where everyone needs to be.Copilot, Microsoft's AI assistant, reads through all of it to help people work.And behind the scenes, the IT team uses Microsoft's own tools to manage security, and passwords.All of these feel like separate products, but many of them lean on the same foundations underneath.And on Thursday, one of those foundations cracked.It's called Exchange Online, the service that stores and delivers your email.Your Outlook app doesn't actually hold your email.It's more like a window.Your real mailbox lives on a server in a Microsoft data center, and every time you open Outlook, your app reaches out and asks that server, anything new?On Thursday, a large number of those servers stopped answering.Now, it's important to be precise here.Not everything went dark.Microsoft said that core chat and online meetings in Teams were still largely working, and files in SharePoint could still be opened.
But anything that needed to talk to your mailbox was in trouble.Teams calendars, meeting scheduling, Copilot when it tried to read your mail, even some of the security and admin dashboards that IT teams use to fix problems exactly like this one.So, the people whose job is to fix things were partly stuck, too.They couldn't easily see what was broken, and they couldn't email their own staff to tell them.Think of a Jenga tower.Pull out one block near the bottom, and everything resting on it starts to wobble.
Explains how companies moved from local servers to shared cloud services and why that creates systemic risk. Uses simple analogies to show how one provider can connect unrelated institutions to the same failure point.
20 years ago, if a company's email broke, it was that company's problem.They had their own email server in their own building, often sitting in a cupboard next to the printer.If it died, one office had a bad day, and nobody else on the planet noticed.Today, almost nobody runs their own.Companies, schools, councils, hospitals, railways, they rent their email, their files, and their meetings from a cloud provider.They pay a monthly fee per person, and the provider runs everything else.And it makes a lot of sense.A cloud company has better engineers, better security, and more backup power than any single business could ever afford.It applies security fixes for you.It keeps copies of your data.Most of the time, it's far more reliable than that server in the cupboard ever was.But there's a catch.When millions of organizations rent from the same provider, they're sharing the same machines, the same network, the same software, the same updates.
Engineers have a word for this, multi-tenant.Think of a giant apartment block.Every company gets its own locked apartment and nobody can see into anyone else's, but they all share the same lifts, the same plumbing, and the same electricity.If the water main bursts, it doesn't matter how good your lock is, every apartment gets wet.And there aren't many buildings to choose from.Three companies, Amazon, Microsoft, and Google, hold about 63% of the world's cloud infrastructure market.Microsoft alone has about a fifth of it.So the world didn't end up with millions of separate systems.It ended up with a handful of enormous shared ones.That's why a railway in Germany, a visa office in New Zealand, and a hospital in Canada all had problems on the same day.They weren't connected to each other.They were all connected to the same thing.
Breaks down what likely happened inside Microsoft's data centers, including health checks, load balancing, and cascading failure. Describes how overloaded secure-connection processes and a recent configuration change may have contributed.
So what actually went wrong inside those data centers?Microsoft hasn't published a final root cause, but during the outage, it posted a running commentary.And if you read it carefully, you can piece together a surprisingly clear picture.First, you need to know how a service like this handles millions of people at once.It doesn't use one giant computer.It uses huge fleets of ordinary servers all doing the same job side by side.When you open Outlook, a system in front of them called a load balancer picks a server that isn't too busy and sends you there.To keep this running, the system constantly checks on every server.Are you alive?Are you responding?If a server stops passing these automated health checks, it's taken out of service, so nobody gets sent to a broken machine.Most days this is exactly what keeps things running smoothly.
Here's a way to picture it, and this is an analogy not a map of Microsoft's real buildings.Imagine a huge office lobby with a hundred reception desks.Visitors arrive all day and every desk takes its share.A supervisor walks the floor and if a receptionist stops responding that desk gets closed and visitors are sent to the others.Now imagine a lot of desks close at once.The visitors don't stop coming.They just pile up at the desks that are still open.Those receptionists are suddenly handling double triple their normal crowd.They slow down.Some stop responding.The supervisor closes those desks too and now the pressure on the remaining desks is even worse.That's what Microsoft described.It said a large number of servers were failing their health checks and being taken out of service and it said something really important.The extra load wasn't caused by more people using email.
It was caused by servers being unexpectedly unavailable which strained the infrastructure that was left.Engineers call this a cascading failure.The safety system that removes a broken server is doing its job, but if too many go at once the healthy ones inherit all their work and start breaking too.Microsoft also found where the strain was landing.It said a process on the affected servers, the one responsible for setting up secure connections, was becoming overwhelmed.Every time your app talks to Microsoft the two sides first do a kind of digital handshake.They check each other's identity and agree on a secret code so nobody in between can read your email.It happens in a fraction of a second, but it takes real work.Now multiply that by millions of apps all trying to connect at once to fewer and fewer servers.The handshake desk becomes the bottleneck.
At this point you might be thinking hang on, Microsoft has data centers all over the world.Surely there are backups and there are.Your mailbox isn't stored in one place.It's copied across several machines, usually in different buildings.If a hard drive dies, nobody notices.If a whole building loses power, traffic moves somewhere else.Engineers call this redundancy and the cloud is very very good at it.But redundancy protects you from one kind of failure, something breaking in one place, a fire, a flood, a dead machine.It doesn't protect you from the same problem happening in lots of places at once.Picture a restaurant chain with a thousand kitchens.If one kitchen catches fire, the other 999 keep cooking.That's redundancy.But if head office sends every kitchen the same wrong recipe, all thousand kitchens serve the same bad meal.More kitchens doesn't help.It just means more people get the bad meal.
In the cloud, the recipe is the software and the settings.Every copy of your mailbox runs the same software.Every server follows the same rules for handling traffic.So if something goes wrong with the rules themselves, the backup copies can have exactly the same problem as the originals.Engineers call this a correlated failure and those rules change all the time.Nobody logs into each server by hand.Engineers write settings, rules for how traffic should flow and which servers handle what and automated systems push them out to huge numbers of machines.That's what makes the cloud cheap and fast.One engineer can improve thousands of servers in minutes, but it cuts both ways.If a setting has a mistake in it, the automation spreads the mistake just as quickly.Engineers call how far a single change can reach the blast radius.To shrink that blast radius, cloud companies use staged rollouts.
A change goes to a small group of servers first.Engineers watch.If nothing breaks, it goes wider.It's like a food taster for software.But some problems only appear under real heavy traffic.Some take hours to show up, and by then a change can already be everywhere.We don't know yet whether a change like that caused this outage, but during the outage Microsoft said it had begun reverting a recent network configuration change that lined up with when the trouble started.That's not a confirmed cause, but it tells you where the engineers were looking.
Shows how engineers tried to restore service by restarting servers, rerouting traffic, and rolling back changes. Explains why recovery from a cascading failure has to be gradual and carefully controlled.
When something breaks, the first thing anyone tries is turning it off and on again.Microsoft's engineers did exactly that.They restarted servers, and at first it looked like it was working.Microsoft said the restarted servers initially came back healthy, but they could become unresponsive again as soon as they started receiving traffic.Go back to the lobby.You reopen a reception desk, but there's a crowd of visitors who've been waiting for hours.The moment that desk opens, everyone rushes to it at once, and the receptionist who just came back is instantly swamped.That's what happens with apps.For hours, millions of them had been trying to reach their email and failing.Outlook on laptops, Outlook on phones, every team's calendar, every automated system that sends or checks mail, and every one of them is programmed to do the same thing when it fails.Wait a moment and try again.
Good software tries to be polite about it.It waits a second, then two, then four, so the crowd spreads itself out.But when millions of apps are all knocking on the same door, even polite knocking adds up to a roar.Engineers call it a thundering herd.So Microsoft had to try something smarter than switching things back on.Over the following hours, its updates described a whole toolbox.It shunted traffic onto alternative routes and infrastructure to take pressure off the struggling servers.It started limiting which kinds of traffic could reach them, like a bouncer letting people in a few at a time.It isolated part of the infrastructure so it could test fix without the crowd crashing in.It rebuilt some servers using a previous software configuration, an older setup that it knew had worked, and it began reverting that recent network configuration change.At one point, Microsoft said it was opening all available pathways to restore service because the actions it had taken so far hadn't provided the relief it expected.
That's not a sign that nobody knew what they were doing.It's what fixing a cascading failure actually looks like.You can't just flip a switch.You have to bring capacity back slowly, a little at a time, watching to see if the system can hold it.Bring it back too fast and the crowd knocks it over again.Too slow and the outage drags on for hours.As I record this, Microsoft says service is coming back in stages, and it still hasn't published a final root cause.
Places the outage in the context of other major cloud and software failures, emphasizing that these are usually not hacks. Concludes with practical advice for organizations and individuals on preparing for cloud disruptions.
If this feels familiar, that's because it is.In July 2024, a cybersecurity company called CrowdStrike pushed out a faulty update to its software.It crashed about 8.5 million Windows computers.Airlines grounded flights, hospitals and government agencies were disrupted.In October 2025, it was Amazon's turn.A hidden flaw in the automation that manages internet addresses for one of its databases left an important address record empty.One region of Amazon's cloud in Virginia struggled for more than 14 hours, and a huge number of apps and websites went down with it.Nine days later, it was Microsoft.An accidental configuration change in a system called Azure Front Door, basically the front entrance to a lot of Microsoft's online services, knocked services out for hours.Different companies, different systems.But look at the pattern.None of these was a hack.And on Thursday, Microsoft said there was no indication of malicious activity either.
An outage isn't the same as a cyber attack.Most of the time, the biggest failures start with a small change made by trusted people pushed through automated systems to millions of machines that all depend on the same thing.So why not just go back to the server in the cupboard?Because most days the cloud is still the better deal.A small business can't hire a team to watch its email at 3:00 in the morning.A cloud provider can.The cloud swaps lots of small failures that nobody hears about for rare, huge failures that everybody hears about at the same time.And splitting everything across several clouds sounds easy, but it isn't.It means building and paying for the same system two or three times and keeping all the copies in sync.For most organizations, that's simply too expensive for something that goes wrong once or twice a year.
The smart move isn't to leave, it's to plan for the bad day.Big organizations keep a backup way to communicate that doesn't depend on the same provider.Some split their most important systems across more than one cloud.And for you, it's simpler.Keep important phone numbers somewhere that isn't your email.Keep a copy of the files you can't live without.And when everything goes quiet, check whether it's just you before you restart your router five times.That's the system hiding behind your inbox, an app that's really just a window, a mailbox that lives in someone else's building, services stacked on top of each other like Jenga blocks, reception desks that keep the crowd moving untiltoo many close at once, backups that protect you from fires, but not from a bad instruction, and a crowd of apps waiting at the door.We spend our days looking at the screens in front of us, but behind every email, every meeting, and every file, there's an enormous system working quietly in the background.
It works so well that we forget it's there until one day in 74 countries at once, it reminds us.There are thousands of systems like this running behind your day.Taking you behind them is what this channel is for.I'm the World Backstage.See you behind the scenes.