The email was not arriving. Meeting calendars would not load. Across time zones, people were discovering that the tools they used to run their day had stopped answering at the same time.
At a glance: A Microsoft 365 outage disrupted Outlook email and features in services including Teams around the world.
Cause: Microsoft identified failing servers but had not confirmed the underlying cause. It said there was no indication of malicious activity.
Cost: A reliable global loss total and a dollar figure for damage to Microsoft's reputation were not available in the reports reviewed on November 13.
On November 12, 2026, a disruption to Microsoft 365 spread beyond Outlook and Exchange Online into features of other services that depend on them. By the following morning, companies and government offices were still dealing with the fallout. In Singapore, government email was affected; in the Philippines, the Supreme Court said some of its operations, including email responses, were disrupted. An Indian airline said its email support was affected while its flights continued. The impact varied by service and customer. The Associated Press documented the disruption across several countries.
For anyone unable to reach their mailbox, the immediate decision is whether the problem belongs to their account or to the service. Check Microsoft's service health page and, for a work account, ask your administrator to check incidents EX1550543 and MO1550821. An outage alone is not a reason to reset your password or reinstall Outlook. If there are separate signs of unauthorized access, follow the steps to recover a hacked Microsoft account.
How the outage unfolded
Hacked.com assembled this timeline from Microsoft service-health notices republished by the University of Pennsylvania. Times are UTC. Incident start times are Microsoft's recorded times, while the later entries are times of its updates, not necessarily the exact moment each event began.
- November 12, 16:17: Microsoft recorded the start of the Exchange Online incident, EX1550543, involving mailbox connectivity.
- November 12, 18:26: Microsoft recorded the start of a wider Microsoft 365 incident, MO1550821, covering affected services that interact with Exchange Online.
- November 12, 19:18: Microsoft said unavailable servers had shifted load to the remaining infrastructure. It was investigating why those servers became unavailable.
- November 13, 03:34: Microsoft said there was no indication the incident resulted from malicious activity.
In an update at 09:55 UTC on November 13, Microsoft still listed the Exchange incident as ongoing and had not published a root cause in that incident record. The chronology shows how its assessment evolved; it does not establish the initial trigger or a full resolution time.
The failure behind the empty inbox
Outlook is the window many people see. Exchange Online is part of the machinery behind it: a cloud service that stores and delivers email and provides calendar data to other applications. When that shared machinery fails, the effect can reach much further than a blank inbox.
According to Microsoft incident updates republished by the University of Pennsylvania, some users could not access mailboxes through Outlook on the web, desktop applications or mobile connections, and mail delivery could be delayed. Affected features differed across Microsoft 365. Teams calendars and meeting scheduling could fail, even though core Teams chat and meetings remained largely functional. A service can be partly working and still leave a crucial task unfinished.
The number of reports gives a sense of the disruption, but not its full scale. AP reported more than 130,000 Outlook problem reports at a peak on Downdetector. Those are voluntary reports, not a census of affected users, and they cannot establish the total number of customers or hours lost.
Why a server problem can become a worldwide problem
Microsoft's explanation changed as its engineers gathered evidence. At first, the company reported elevated infrastructure load. It later said the load was not caused by an overall increase in traffic: many servers had unexpectedly become unavailable, shifting work onto the servers still running. It then identified a process responsible for establishing secure connections that was becoming overwhelmed. Computerworld reported that some servers became unresponsive again when traffic returned.
Think of a busy road after several lanes close. Traffic has not necessarily increased, but fewer lanes must carry it. Reopening a lane helps only if it stays open when cars return. In cloud infrastructure, automatic retries and recovery actions can add pressure too. Microsoft reported a surge in calls to backend servers as it rebalanced traffic. This is an explanation of the reported failure pattern, not a claim that every part of the causal chain has been established.
There is also a possible triggering event to investigate. Microsoft was reverting a recent network configuration change that correlated with the start of the disruption, according to Computerworld. A change occurring near an outage is a lead, not proof that it caused it. The distinction matters: the initial trigger, the reason the failure spread, and the reason recovery took time may turn out to be different things.
Was Microsoft hacked?
Microsoft said it had no indication that malicious activity caused the outage, AP reported. That does not prove every question has been answered, but it is the evidence available. There is no basis in the reporting cited here to say this was a cyberattack, that customer data was stolen, or that the outage itself exposed private messages.
Confusion creates its own opportunity for fraud. A message claiming to restore your mailbox can be a phishing attempt. Open the status page or Microsoft app directly rather than following an unexpected link, and never give a caller a password or a one-time sign-in code. If you receive a sign-in alert you did not initiate, treat it as a separate security issue. Check your account directly through its normal security settings.
The global bill: real disruption, no reliable total yet
The immediate losses are scattered across organizations and may never appear on one invoice: a delayed customer response, an employee unable to finish a task, an IT team pulled into triage, an appointment that has to be rearranged. Some work can be recovered later. Some opportunities and hours cannot. The same delayed email should not automatically be counted as an entire lost sale.
A responsible estimate would need the number of affected people and organizations, the features they lost, how long each was impaired, the value of work actually lost, and the cost of recovery. It would also need to avoid counting the same disruption twice as it moves between a supplier and a customer. Those inputs were not available for a defensible worldwide total in the reporting reviewed on November 13.
There is a tempting comparison, but it must be handled carefully. Cyber insurer Parametrix estimated $5.4 billion in direct losses for US Fortune 500 companies, excluding Microsoft, from the separate July 2024 CrowdStrike outage. That incident involved a faulty CrowdStrike update affecting Windows devices and disrupted different systems. The figure is an estimate for a defined group in a different event, not the cost of this Microsoft 365 outage and not a basis for extrapolating one.
For an individual organization, a useful starting calculation is affected staff multiplied by genuinely unrecoverable productive hours and an appropriate hourly cost, then add documented extra expenses and demonstrably lost business. Keep assumptions visible and avoid adding delayed work that was completed later. Even a simple estimate can help identify which dependency deserves a backup.
What Microsoft may have to pay
Microsoft faces its own incident-response and support costs. Some business customers may also qualify for service credits, depending on their agreement, the affected service, the measured availability and the claims process. Microsoft's guidance for partners says credits depend on the affected service and require evidence of impact. A credit against a service fee is not the same as reimbursement for a customer's lost revenue, and eligibility for this particular incident cannot be assumed.
The less visible exposure is commercial. Large customers may ask harder questions during renewals, request clearer recovery commitments or invest in alternatives for critical tasks. Those are plausible consequences, not confirmed losses or proof of customer departures. The scale of any effect will depend on the duration of the incident, Microsoft's explanation and whether customers believe the risk has been reduced.
The cost to a brand built on being available
Microsoft sells more than software. It sells the expectation that a business can send the contract, a family can retrieve a document and a colleague can find the meeting. The outage puts that expectation under stress precisely because the products have become so useful and so interconnected.
Brand damage does not arrive as a neat line on a balance sheet. A falling share price on one day would not isolate the effect of this incident from other market news; an outage report does not measure customer loyalty. The better evidence would emerge over time: renewal decisions, credible customer surveys, changes to purchasing requirements and Microsoft's own disclosures. None establishes a dollar value for this incident yet.
There is also a test of communication. Early incident reports are necessarily incomplete, but customers need to know what is affected, what still works and when the next update will come. A clear post-incident report explaining the trigger, the spread and the changes made afterward would give customers something more useful than reassurance alone.
What to do while service is unstable
- Check the scope. Use Microsoft's status page and ask your organization's administrator for the relevant incident updates. A green general status does not necessarily settle an individual account problem.
- Use another channel for urgent matters. Confirm time-sensitive arrangements by phone or another trusted service. Do not assume a delayed email has been delivered; verify important messages with the recipient.
- Keep the account safe. Avoid unsolicited recovery links, calls and requests for codes. If you have independent evidence of compromise, follow the Microsoft account security steps appropriate to your account.
- Record business impact. Administrators should document affected services, times, users and support tickets, then review the applicable contract and claims requirements.
When the inbox returns
Restoration will solve the immediate problem. It will not answer every question about why the failure began, why recovery was difficult or how much work was lost. Those answers require evidence that is still emerging.
The incident shows the tradeoff behind a convenient cloud suite: shared infrastructure makes everyday work easier, but a fault in a common dependency can cross the boundaries between products and organizations. The lasting measure for Microsoft will be whether its explanation and corrective work make that dependency more trustworthy when the next failure comes.