At 8:17pm Dubai time on Thursday, the mail stopped.
Not for one company. Not for one region. For a very large slice of the planet, at the same moment, on the same evening. Outlook went blank. Exchange Online mailboxes refused to open. Teams calls dropped into silence. Copilot answered with an apology. SharePoint links spun. Somewhere around 131,000 people opened Downdetector in the first hours to check whether it was them, and the reports came from 74 countries and territories inside about sixty minutes.
We watched it the least glamorous way possible: a terminal, a handful of probes, and a clock. At 16:44 Dubai the next afternoon, more than twenty hours in, outlook.office.com and outlook.office365.com still would not complete a TCP handshake from here, while graph.microsoft.com, login.microsoftonline.com and teams.microsoft.com answered in milliseconds. That single asymmetry told most of the story before Microsoft said a word: this was not the internet breaking, and it was not a routing accident somewhere in the Gulf. It was Microsoft's own front door, and it was jammed.
Our own mail never moved. aratech.ae runs on Migadu, so our inboxes were up the whole time. That is not a boast, it is the entire lesson of this outage compressed into one sentence, and we will come back to it.
What actually broke
Microsoft's own status feed describes it in a way that should make every infrastructure engineer sit up: a core process on the affected servers, the one responsible for establishing secure connections, became overwhelmed. When that process saturates, the server stops processing requests. Not slowly. Not partially. It stops. The servers then failed their own internal health checks, traffic was shifted away from them, and the platform started restarting them.
That is where the recovery turned into a loop. Restarted servers came back healthy, took traffic, and went unresponsive again. Microsoft said so directly: servers that caused the outage "can become unresponsive again once they receive traffic." Which is why, for a stretch of the night, the company was deliberately limiting which types of traffic were even allowed to reach the affected infrastructure in some locations. When a provider starts blackholing its own customers' requests to protect a service from being loved to death, you are not looking at a bug. You are looking at a capacity and control-plane failure with a restart loop on top.
ThousandEyes, watching from the outside, saw exactly what that looks like on the wire: connection resets, connection refusals, response timeouts, HTTP server errors, and significant packet loss inside Microsoft's own network. Not at the edge. Inside.
Microsoft's first timeline put the start at 16:17 UTC on 12 November. ThousandEyes observed impact from around 17:30 UTC. That gap matters, because it is the difference between the moment a system breaks and the moment a system admits it.
Two things Microsoft has been clear about, and both deserve to be repeated rather than buried: there is no evidence of malicious or cyber activity, and a full post-incident report with root cause and defense-in-depth actions will follow once mitigation is complete. Until that report lands, any confident explanation you read, including a more detailed version of this one, is inference dressed up as fact.
Why one process took down eleven products
Here is the part that should worry you more than the outage itself.
The list of affected services was not a list of products that happen to share a data center. It was Outlook, Exchange Online, Teams, SharePoint Online, Copilot, Defender XDR, Defender for Office 365, Planner, To Do and Intune. Read that list again and notice what it has in common: almost every one of them either reads from, writes to, or authenticates through Exchange Online.
Exchange is not just email. In a Microsoft 365 tenant it is the notification bus, the calendar spine, the meeting invite, the approval email, the password reset, the alert that a backup failed, the ticket that says a server is down. When the mail plane stalls, the control plane of the business stalls with it, and it stalls in ways nobody documented because nobody ever drew the graph.
That is the real finding of this week, and it is not a Microsoft finding. It is an architecture finding. The dependency graph of a modern business is a hub-and-spoke diagram with a vendor logo in the middle, and most companies have never seen their own copy of it.
The 48-hour window, and what it actually means
At 04:15 ET on Friday, Microsoft extended the email timeout window to 48 hours.
Read that as an engineering confession. A timeout window is how long a mail server or client will keep waiting for a message before it gives up and returns an error. Extending it to 48 hours means Microsoft expects messages to sit in queues for a very long time while it drains the backlog, and it would rather hold them than have them bounce. Practical consequences, in order of how much they will cost you:
Messages sent to your users from Gmail, Outlook.com and other healthy providers during the outage are likely queued, not lost. They will arrive late, in a burst, out of order, and mixed in with everything else.
Messages your users sent during the outage may show as sent and never leave, or leave twice, depending on how the client cached them. Duplicate invoices and duplicate payment reminders are a real risk this week.
Anything with a deadline inside the window was missed. Tender submissions, visa documents, bank instructions, contract signatures. Email is still the legal record for most of these in this region, and the record has a hole in it.
What the world actually lost
The impact list reads like a stress test of civil infrastructure, which is what it was.
The UK's NHS email system was disrupted badly enough that some patients were expected to miss prescriptions. Police forces in Merseyside, Greater Manchester, Bedfordshire, Dorset and Hertfordshire told the public to call 101 because online forms were dead. The parliamentary network in Westminster was affected. In the United States, the House of Representatives said its engineers were working with Microsoft, city governments from Miami Beach to Austin to Baltimore County told residents to pick up the phone, and the Arapahoe County Sheriff's Office reported delayed bail payments. Workhorse Group postponed its quarterly earnings call. OpenAI reported problems with Microsoft connectors, and Anthropic had to deploy a fix after a wave of Claude errors.
Not one of those organizations lacked an IT department. Most of them had a business continuity plan. What they did not have was a plan for the specific case of "the vendor's control plane is in a restart loop and our identity provider is inside it."
The uncomfortable arithmetic for this region
Microsoft 365 is used by hundreds of millions of people, and the concentration is not evenly distributed. In the Gulf, it is close to a default. Banks, free zone authorities, clinics, schools, logistics firms, and a very large number of SMEs run their entire working day through a tenant that was, for about a day, the least reliable piece of software they owned.
Now the part that should sting. This outage began at 20:17 on a Thursday in Dubai. In a Sunday-to-Thursday working week, that is the single best possible moment for it to happen: after the week's work was sent, before anyone needed to answer anything. If the same failure had landed at 09:00 on a Sunday, the region's week would have started with a dead inbox and no way to tell clients why.
That is not resilience. That is luck, and luck is not a control you can put in a risk register.
What we would do on Monday morning
Not a vendor pitch. A checklist. Most of it costs time, not money, and all of it is cheaper than Thursday night was.
1. Draw the dependency graph, honestly. Write down every business process that stops when email stops: invoicing, one-time codes and two-factor codes delivered by mail, e-signature, ticketing, password resets, CRM notifications, backup alerts, payroll approvals. Then mark which of those have a non-email path. In most companies the honest answer is "none of them," and that is the finding.
2. Get identity out of the mail path. If password reset, MFA enrolment and account recovery all run through the same mailbox that just went dark, one outage becomes a total lockout. Break-glass admin accounts with hardware keys, recovery codes stored offline, and an out-of-band admin channel are not paranoia. They are the difference between an incident and a standstill.
3. Keep a second door open. A secondary mail provider on a separate MX record, or at minimum a documented, tested procedure to flip MX records and stand up a fallback mailbox, turns a 20-hour outage into a 20-minute annoyance. It is not free, and it is not for everyone, but the calculation changed this week.
4. Monitor the user journey, not the ping. A green ICMP check on a Microsoft IP told you nothing on Thursday. What you needed was a synthetic login to the web mail client, an actual send-and-receive test message every five minutes, and an alert when the round trip breaks. Monitor the thing your staff do, not the thing that is easy to graph.
5. Write the comms runbook before you need it. Who tells clients, on which channel, with what words, and who owns the decision to switch channels. SMS and WhatsApp worked perfectly on Thursday. Almost nobody had a pre-approved message ready to send on them.
6. Know what your SLA is actually worth. Microsoft's service credits for an outage of this length are a rounding error against a lost day of a trading business. The SLA is a refund policy, not a continuity plan. Budget accordingly.
7. Read the post-incident report when it lands, and translate it into your own risk register. Microsoft has promised root cause and defense-in-depth actions. Whatever they publish, the question for you is not "what did Microsoft get wrong," it is "what in our stack has the same shape."
The bill arrives later
Outages like this are remembered as a bad Friday and forgotten by the following Wednesday. The cost does not disappear, it just gets distributed: the deal that slipped, the invoice that was paid twice, the client who quietly started wondering whether your email is a reliable way to reach you.
The honest summary is this. A single saturated process inside one vendor's infrastructure took out mail, chat, files, AI assistants, security telemetry and endpoint management for a large part of the world, for the better part of a day, and the recovery only held once the provider started throttling its own customers. No attacker required. No zero-day required. Just a dependency graph nobody had drawn, and a restart loop nobody had rehearsed.
We build and run infrastructure for a living, and we are not exempt from any of the above. The only difference is that we spent Thursday evening watching the probes instead of the inbox, and we already knew which of our clients would feel it first. If you do not know that about your own business, this week gave you a free rehearsal. Use it before the next one costs you something.