The Microsoft 365 Outage: What It Costs Your Business and How to Stop Paying for It

On 12 November 2026, a core process on Microsoft’s Exchange Online servers became overwhelmed, the servers stopped responding, and roughly a third of the modern corporate workplace went dark for the better part of a day.

The mechanics matter, because they explain why the fix took so long. Exchange Online servers started failing Microsoft’s own automated health checks. A server that fails a health check gets pulled out of rotation, which is normally correct behaviour. But with a large number of servers dropping out at once, their traffic landed on the servers still passing checks. Those servers then saturated, failed their own checks, and dropped out too. A feedback loop chewed through regional capacity faster than Microsoft could restore it.

Microsoft was explicit that traffic had not increased. The load came from servers becoming unexpectedly unavailable, not from users doing anything unusual. Microsoft logged the incident as EX1550543 for Exchange Online and MO1550821 for the wider suite, and stated it had no indication of malicious activity. This was not a cyberattack.

The recovery was the painful part. Microsoft restarted affected servers, and they came back healthy, then became unresponsive again the moment real traffic reached them. Fixes, in Microsoft’s own wording, did not provide the anticipated relief. Teams recovered first. Exchange Online stayed stubborn, and with it, every business process that runs on email.

Most outages take down one tool. This one took down the tool, the tools that depend on it, and the tools you would use to diagnose it.

Exchange Online is not just Outlook. It holds mail, calendars, and contacts, and dozens of other services call it constantly. So when Exchange went down, the damage spread along the dependency chain: Teams calendar broke because the calendar lives in Exchange. Copilot 365 broke because it reads your mail and meetings. Defender for Office 365 broke because it scans mail that was no longer moving. Microsoft was clear that the parts of those services that do not touch Exchange kept working, which is precisely why the failure was so confusing on the ground. Teams chat worked. Teams calendar did not. Users could not tell whether the problem was Microsoft, their laptop, or their account.

The second-order problem was worse. Admins trying to work out what had broken found that Intune and the Microsoft 365 Apps Admin Center had gone down too. The instruments went down with the engine. An IT team cannot push a device policy, cannot check tenant health, and cannot tell its own staff what is happening because the channel it would use to tell them is the channel that is down.

This is the concentration risk that has been building quietly for a decade. A single vendor runs your email, your chat, your file storage, your identity layer, your endpoint management, and your security tooling. The commercial logic is excellent. The failure logic is not: one shared dependency means one shared failure, and no amount of internal redundancy helps when the dependency is outside your walls.

It is worth noting the political backdrop. The outage landed while Europe is actively seeking to reduce its reliance on US technology providers, and it hit government operations in multiple countries Australia’s federal police and intelligence agency were among the organisations affected. Concentration risk is no longer only an IT conversation. It is a board and procurement conversation.

The cost of an email outage is not the email. It is everything that was waiting on the email.

The first hour is confusion, not downtime. Staff assume the problem is local. They restart Outlook, reboot laptops, re-enter passwords. The service desk fills with tickets that have no fix. Some users on Reddit reportedly panicked and assumed they had been laid off when their work email stopped authenticating. An hour of an entire workforce’s attention goes to diagnosing something nobody in the building can fix.

Hours two to four, revenue processes stall. Quotes do not go out. Purchase orders sit unsent. Signed contracts bounce. Customer enquiries land in a mailbox nobody can open, and the sender gets no delivery failure so they assume they have been ignored. Sales calls get rescheduled because the calendar invite never arrived. Nothing is lost yet, but everything is late.

Hours four to eight, the dependencies surface. This is where most businesses discover what they actually built on email. Order confirmations from the e-commerce platform. Password resets. Two-factor codes delivered to mail. Approval workflows that route through Outlook. Automated invoices. Vendor onboarding. Shipping notifications. CRM sync. None of these are described as “email” in any internal document, and all of them stop.

Beyond eight hours, the backlog becomes the problem. When service returns, mail does not arrive in a civilised trickle. It arrives all at once, out of order, mixed with duplicates and retries. Queued messages from eighteen hours of delayed delivery hit the inbox simultaneously. Your team’s first full day back is not productive work it is triage, and triage is where things get missed. The commitment buried at message 400 of 600 is the one that becomes a customer complaint next week.

There is a human cost running underneath all of this. Medical workers were affected. NDIS clients in Australia were described as stressed by the email outage. When mail is how a vulnerable person reaches a service they depend on, an outage is not an inconvenience. And some workers, candidly, took the enforced quiet as a Friday off, which is its own kind of cost, and an entirely understandable one.

Any blog that hands you a per-minute downtime figure is selling you something. Published averages are drawn from enterprises with call centres and trading desks, and they will overstate the loss for a 40-person firm by an order of magnitude. The number that matters is yours, and it takes about twenty minutes to produce.

There are four components, and most businesses only ever count the first.

1. Idle labour. The easy one, and the smallest.

Idle labour = staff affected × hours down × fully loaded hourly cost × productivity loss %

Use a productivity loss figure between 0.3 and 0.6 for knowledge workers; almost nobody is fully blocked, because people switch to other tasks. Be honest here; inflating it undermines the rest of the case.

2. Deferred and lost revenue. Take your average revenue per working day and ask what fraction genuinely travels through the affected channel. For an e-commerce business whose storefront stayed up, the answer may be small. For a B2B firm where every quote, order, and approval moves by email, it approaches 100%. Then split it: revenue that is merely deferred arrives late, and revenue that is lost went to whoever replied first. The lost portion is small in percentage terms and brutal in effect, because it usually leaves with a customer attached.

3. Recovery cost. The backlog triage, the overtime, the support tickets, the duplicate orders to unpick, the apologies to write. This routinely exceeds the idle-labour figure and is almost never counted, because it lands the following week under a different budget line.

4. Contractual and reputational exposure. The expensive one. If you have SLAs with your own customers, a day of unreachable email can put you in breach, and your provider’s SLA credit will not cover what you owe downstream. If you are in a regulated sector, missed notification windows carry their own penalties

One caution worth stating plainly, because it changes the maths: cloud provider SLA credits are a refund of a portion of your subscription fee. They are not compensation for your business losses, and they are typically claimed, not automatic. Nobody in this outage was made whole by a credit. Budget accordingly.

The damage was not evenly spread. It tracked almost exactly with how much of a business’s critical path runs through email rather than through its own systems.

The pattern is worth sitting with. The businesses that sailed through were not the ones with the biggest IT budgets. They were the ones whose revenue-critical systems the storefront, the POS, the booking engine were architecturally separate from their productivity suite. That separation is usually accidental. It does not have to be.

The other group that coped well had something simpler: a communication channel that was not Microsoft. A WhatsApp group, a Slack workspace, a phone tree. Unglamorous, and the difference between a confusing day and a lost one.

Do this while the outage is still fresh and people still remember what they could not do. In two weeks, the organisational memory will be gone, and the budget conversation will be much harder.

Step one: write down what actually broke. Not what IT thinks broke — ask the teams. Sales, finance, operations, support. The question is specific: what were you unable to do, and what did you do instead? The workarounds people invented under pressure are the most valuable output of the whole exercise, because they are your unwritten continuity plan.

Step two: map the hidden dependencies. This is the one that surprises people. Walk your systems and list everything that sends or receives mail through Microsoft 365:

That last item catches almost everyone. If your monitoring alerts route to Outlook, an email outage is invisible to your alerting system by definition.

Step three: separate the critical path from the convenient path. For each dependency, one question: if this is unavailable for a full working day, does the business stop or merely slow? Only the “stop” items need real investment. Everything else can wait for a manual workaround. This is what keeps a continuity plan affordable.

Step four: set up the channel you will use next time. Decide now, in writing, how your team communicates when Microsoft 365 is down, and make sure everyone has it on their phone before they need it. Then tell your customers. A status page on your own domain independent of your mail provider and a pre-written holding message turn “they have ignored me for a day” into “they told me, and they handled it.” The reputational difference is enormous, and the cost is close to nothing.

Step five: write the incident into your risk register properly. Not “Microsoft outage resolved.” Record the dependency map, the hours lost, the departments affected, and the gaps you found. The next time someone asks why continuity work deserves budget, that document is the entire argument.

Leaving Microsoft is not the answer, and anyone telling you otherwise is ignoring the cost. Every provider has outages. The goal is not a different single point of failure it is making sure your revenue does not stop when your productivity suite does.

Decouple transactional email from corporate email. This is the highest-value change available to most businesses, and it is usually a day of work. Order confirmations, password resets, OTPs, and system alerts should not travel through the same infrastructure as your staff inbox. Route them through a dedicated transactional provider: SendGrid, Postmark, Amazon SES, Resend. When Exchange Online falls over, your customers still get their order confirmations and can still reset their passwords. Your staff have a bad day; your customers do not notice.

Keep identity independent of your mail provider. If the only way into your systems is a Microsoft login, then a Microsoft outage locks you out of everything you own. Make sure critical systems support an alternative authentication path, and that break-glass admin credentials exist on paper, offline, and are tested.

Own your customer-facing surface. Your website, storefront, booking engine and customer portal should run on infrastructure you control, independent of your productivity suite. The businesses that kept selling through this outage were the ones whose storefront had no dependency on Microsoft at all. If your e-commerce platform’s order notifications route through a corporate mailbox, that is a thread worth cutting.

Build a status channel on your own domain. A simple, statically hosted status page, separate from your main stack, that you can update when everything else is down. It costs almost nothing and it is the single best reputational insurance available.

Fix queueing and retry behaviour. Many of the worst outcomes from this outage were not caused by the outage; they were caused by systems that failed silently, dropped messages rather than queueing them, and gave users no indication anything had gone wrong. Integrations should retry with backoff, queue durably, and surface failures loudly. That is an engineering decision, and it is reversible.

Test it. A continuity plan nobody has rehearsed is a document, not a plan. Run a half-day exercise where email is assumed unavailable and see what your team actually does. You will find gaps, and you will find them cheaply.

Most of what we have described is an architecture problem wearing an IT outage costume. The businesses that came through 12 November with a slow day rather than a lost one had made a series of unglamorous decisions about where their transactional mail runs, how their storefront authenticates, whether their integrations queue or drop. Those decisions are all reversible, and most of them are cheaper than the outage they prevent.

That is the work we do. We build and maintain web platforms, e-commerce systems, headless CMS architectures and enterprise integrations for clients across the USA, UK, Singapore and Australia and resilience is part of how we design them, not a separate service we upsell afterwards.

If this outage exposed something in your stack, three places to start:

We will tell you honestly if your exposure is low and you do not need us. Plenty of businesses got through this fine, and a continuity plan sized for an enterprise is wasted money on a 30-person firm.

If you would like someone to look at your stack properly, get in touch with the Kombee team and we will arrange a conversation about where your real exposure sits. We make your work work for you including on the days the internet does not.