Since the afternoon of Thursday, November 12, millions of people around the world have been unable to open their Outlook inbox, join a Teams meeting or use Copilot normally. The Microsoft outage has spread to more than 70 countries and has hit governments, hospitals, airlines and businesses of every size. For many organizations, Friday began with no email, no calendar and no access to the tool where daily work gets coordinated.
In this article we explain what we know about the Microsoft outage so far, what happens to the emails you send while it lasts and, above all, which technical and business lessons an incident like this leaves for any company that relies on the cloud. Because the real question is not only when Outlook comes back, but what would happen tomorrow if the service that went down were yours.
In short: the Microsoft 365 outage was not a cyberattack but a cascading failure: several servers became unavailable, the rest absorbed a load they could not handle, and automated health checks made things worse. Emails are not lost; delivery is retried for up to 48 hours. The lesson for businesses is clear: business continuity has to be designed before the incident, not during it.
What happened in the Microsoft outage
The first problems appeared shortly before 1 p.m. Eastern Time on Thursday. Microsoft started by investigating issues accessing Exchange Online mailboxes in the Americas, but within hours it widened the warning: Microsoft 365 connectivity could be affected in any region. User reports came in from more than 70 countries and territories while Microsoft tried to roll out several fixes, and some of those actions did not bring the expected relief. The official reference for following the incident is the Microsoft 365 status page, which the company updates throughout.
The affected services cover practically the entire productivity suite:
- Outlook and Exchange Online: mailbox access, sending and receiving email, calendar.
- Microsoft Teams: chat and meetings, with uneven recovery depending on the region.
- SharePoint Online and OneDrive: access to shared documents.
- Microsoft 365 Copilot, Defender XDR, Intune and Planner, among others.
The impact went far beyond the office. The UK's National Health Service reported partial disruption, Air India had to temporarily reconfigure its email, and the Richemont group slightly delayed the release of its results. In New Zealand, embassies and consulates of the foreign ministry were affected, and in Japan the economy minister warned of a significant impact given how many people rely on Microsoft software. In New York, the city's emergency management office warned of possible delays in email and online services.
Why Microsoft went down: a cascading failure
The most interesting part of this Microsoft outage, from a technical point of view, is that there was no single culprit. The company has ruled out malicious activity and does not point to a traffic spike either. What it describes is a pattern well known to any team that runs distributed systems: the cascading failure.
According to Microsoft's updates, the sequence looked roughly like this:
- A group of servers becomes unexpectedly unavailable across several regions.
- The rest of the infrastructure absorbs their connections and becomes overloaded.
- The overloaded servers fail automated health checks, so the system pulls them out of service too.
- When they are sent traffic again, they saturate once more, because a central process that handles connections cannot keep up.
To make matters worse, the very component that processes server health status was also having problems. In other words, the mechanism designed to protect the service ended up amplifying the outage. On Thursday afternoon Microsoft validated an alternative method to check that status, which let it bring some servers back online, and from there a phased recovery began: traffic throttling, routing changes and controlled restarts.
Administrators can follow the incident in the Microsoft 365 admin center under codes EX1550543 (mailbox connectivity) and MO1550821 (main advisory), Microsoft's official guide to Microsoft 365 service health explains how to read these posts, tell an incident from an advisory and subscribe to email notifications. If the admin center is not responding, the public status page remains available.
What happens to emails sent during the outage
This is the most common question, and the answer is reassuring: your emails are not lost. Email works with a retry system. If the destination server does not respond, the sending server keeps the message in a queue and tries again periodically.
During this Microsoft outage, the company extended the delivery retry window to 48 hours to protect delayed messages. In practice, this means:
- What you send now may arrive hours late, but it should arrive.
- You may get "delivery delayed" notices: there is no need to resend the message.
- Sending the same email several times only creates duplicates once the service recovers.
- If something is truly urgent, use another channel (phone, messaging) and follow up by email later.
Lessons from the Microsoft outage for your business
No company can stop Microsoft, Google or Amazon from having a bad day. What you can control is how much it hurts you. These are the lessons we find most useful, both for leadership and for technical teams.
1. Have a backup communication plan
If your whole team coordinates on Teams and all your customers write to you through Outlook, an outage like this leaves you literally cut off. Define a backup channel in advance (a messaging group, a phone list, a status page for customers) and make sure everyone knows which one it is. That takes a 30-minute meeting, not a scramble in the middle of a crisis.
2. Identify which processes depend on a single vendor
Many companies discover during a Microsoft outage that their approvals, invoicing or customer support all run through one service. Do the exercise: list your critical processes and note which platform each one depends on. The point is not to abandon Microsoft 365, but to know what stops and to have a plan B for what cannot wait.
3. Design your own systems to fail gracefully
If you build your own software, this incident is a free case study. The chapter on cascading failures in Google's Site Reliability Engineering book describes exactly this scenario: servers that restart, receive all the traffic at once and fall back into a crash loop. Some practices that reduce the risk:
- Health checks that do not take down healthy servers. An overly aggressive health check can pull machines that were merely slow out of service and worsen the overload.
- Load shedding and circuit breakers, to reject part of the traffic in a controlled way before the whole system collapses.
- Multi-region deployments and spare capacity, so that losing a group of servers does not drag the rest down.
- Gradual warm-up, sending traffic back to recovered servers little by little instead of all at once.
These are architecture decisions made when you design your cloud infrastructure. If your platform runs on Azure or AWS, a review of how it is set up (or a well-planned application migration to AWS and Azure) can be the difference between a few minutes of degradation and a full day without service.
4. Monitor and automate recovery
Knowing something is wrong before your customers do is half the battle. Reliable deployment pipelines, well-tuned alerts and tested recovery procedures are part of the daily work of good DevOps and Kubernetes consulting. And they need rehearsing: a recovery plan that has never been tested is just a document.
5. Do not confuse availability with security, but protect both
Microsoft has ruled out an attack, but moments of chaos are fertile ground for phishing: fake emails promising to "restore your Outlook account" or "recover lost messages". Warn your team not to enter credentials on links received these days. And if nobody has reviewed your platform in a while, a preventive security audit is a good place to start.
The other side: memes and patience
As with every major outage, social media filled up with humor. "Microsoft" became a trending topic, with jokes about an "adult snow day" or the service coming back after Christmas, and plenty of messages of support for the Microsoft engineers working on the recovery. Behind the jokes lies a serious reality: a large part of the economy now depends on a handful of platforms.
Frequently asked questions
Was the Microsoft outage a cyberattack? No. Microsoft has said it is not aware of any malicious activity. The cause was an infrastructure failure: unavailable servers, overload on the rest and problems with automated health checks.
When will Outlook work normally again? At the time of writing, Microsoft reports early stabilization and phased recovery, but has not given a timeline for full restoration. The most reliable source is the Microsoft 365 status page or the admin center advisories.
Do I need to resend the emails I sent during the outage? No. Messages stay queued and are retried for up to 48 hours. Resending them will only cause duplicates.
How do I protect my business from an outage like this? With a backup communication channel, a map of which processes depend on each vendor and, if you run your own software, an architecture designed to fail in a controlled way. Our cybersecurity and backup services include disaster recovery plans.
Is your business ready for the next outage?
The Microsoft 365 outage will pass, but the next disruption will come: from Microsoft, from your payment provider or from your own platform. At MiTSoftware we help companies review their cloud architecture, design continuity plans and build software that holds up when something breaks.
