I'm writing this on the morning of Friday 2026-11-13 in Tokyo, and Microsoft 365 has been in trouble since before anyone here got to their desk. We recommend Microsoft 365 to clients as the better alternative to running it yourself. Mornings like this make that a harder sentence to say.
What happened
Microsoft is tracking the outage as two incidents. EX1550543, "Users may be unable to connect to their mailboxes in Exchange through multiple connection methods," started at 01:17 Japan time on Friday, which was 11:17 on Thursday morning in New York. MO1550821, "Users may be unable to connect to multiple Microsoft 365 services," followed at 03:27. Both were still open and marked as service degradation at 09:00.
The latest update to MO1550821 names 14 services. Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot, Planner, To Do and Power BI are on it, and so are Defender XDR, Defender for Office 365, Intune and several Purview services including data loss prevention. So it wasn't mail and chat that were unreliable. The tools that watch for attacks, manage devices and stop data leaving were on the same list.
Microsoft's explanation changed through the night. The times below are Japan time, taken from ITmedia NEWS and Mynavi TECH+ (both in Japanese), WebProNews and a public copy of the incident log. At first Microsoft described elevated load in part of its infrastructure. By 04:30 it said the load wasn't a traffic surge: a number of servers had become unexpectedly unavailable, they were failing automated health checks, and the servers still running couldn't carry the rest. It paused all deployments and configuration changes, moved traffic, restarted servers and bypassed the health check on some of them. Just before 05:00 it said no recent change lined up with the start of the impact. By 06:00 it had found a small number of configuration updates after all and was investigating them as possible contributors. At 07:03 it reported that a core process on the affected servers was being overwhelmed, and at 09:00 that recovered servers were going unresponsive again as soon as they took traffic, so it had started rebuilding some of them on an earlier software configuration.
There's no confirmed root cause yet. We'll update this article when Microsoft publishes its post-incident report.
Where to follow an incident
Those incident numbers come from the Microsoft 365 admin center, the web console at admin.microsoft.com where an organization's administrators manage users, licenses and settings. Its Service health page (under Health) lists every open incident with Microsoft's running updates, usually posted about an hour. an account with an admin role can open it, so the links on the incident numbers above work for your administrators and for nobody else. The limited Service Support admin and Helpdesk admin roles are enough.
There's a phone version too, and it's where I read the updates this morning. The free Microsoft 365 Admin app, for iPhone and iPad and Android, shows the same Service health feed, sends a push notification when an incident opens or changes, and has a share button on each incident so an administrator can pass the details on to everyone else. It needs an admin account as well.
For people without an admin role, Microsoft posts major incidents on its public status page, status.cloud.microsoft, and on the @MSFT365Status account on X. ITmedia reported that the admin center itself was hard to reach during this incident, so it is worth knowing those two before you need them.
Microsoft should do better than this
A company with Microsoft's engineering budget, selling a service that hundreds of millions of people work in all day, shouldn't have a failure in layer of servers spread to mail, chat, files, device management and security tooling in every region. It also shouldn't still be looking for the cause more than seven hours in. Whatever the root cause turns out to be, how far fault can spread is a design decision. Microsoft has the resources to contain it better, and its customers are entitled to say so.
It also isn't a one-off this year. Microsoft publishes a worldwide uptime figure for Microsoft 365 each quarter. Tony Redmond has tracked it since 2013, and through 2025 it never fell below 99.9%. For the first quarter of 2026 it was 99.526%, the lowest in his records, which he works out as roughly 614 minutes of interruption in three months. The second quarter was back to 99.994%.
And the contract doesn't make you whole. Microsoft's Service Level Agreement commits to 99.9% uptime per service, per calendar month, which is about 43 minutes in a 30-day month. Below that, the credit is 25% of the month's fee for the affected service, rising to 50% below 99% and 100% below 95%. Five hours without mail for every user in a tenant works out to about 99.3%, so it still lands in the 25% tier.
The fine print trims it further. Exchange downtime is counted in user-minutes, for the users who couldn't send or receive mail, so a tenant where half the staff were locked out is counted at half. The SLA also excludes "performance degradation or latency issues without actual service unavailability" and says Microsoft's outage notices "are not a confirmation of missed Service Levels." Both of today's incidents are labeled service degradation. Credits, it adds, "will not be awarded to compensate for any other forms of loss, including but not limited to lost revenue." Even where a credit applies, a quarter of month's Exchange fee doesn't come close to what a lost morning costs a business.
What running it yourself costs
So should mail come back in-house? Someone in a sysadmin thread on Reddit did the arithmetic this morning for a 2,200-user organization, and the numbers are worth repeating. They're person's back-of-the-envelope estimates, not quotes, and Microsoft doesn't publish a price list for on-premises Exchange, so we can't check the license figures. The shape of the result is what counts.
| Item | Poster's estimate (USD) |
|---|---|
| Exchange Server SE licenses, Software Assurance, Windows Server licenses and CALs | about 430,000 |
| Three servers able to carry the load | 500,000 at minimum |
| Hardware to start up with a second, redundant site | about 1.5 million |
| Running costs including eDiscovery tooling | about 500,000 a year |
| Two full-time staff, fully loaded | about 300,000 a year |
| Microsoft 365 E3 for the same 2,200 users, after discounts | about 750,000 a year |
Take the last four rows. In-house mail is about 1.5 million dollars to start and about 800,000 a year to run. E3 at 750,000 a year is roughly 28 dollars per user per month. And here is the catch the poster pointed out: you'd keep paying for E3 anyway, because you still want Teams, SharePoint and the Office apps. In-house Exchange doesn't replace the subscription. It gets added to it.
On-premises Exchange isn't a way out of subscriptions either. Exchange Server Subscription Edition, the version Microsoft still supports, requires active Software Assurance or a subscription for the server license and for every client access license.
Scale it down to the size of a typical foreign company's Japan office, a few dozen to a few hundred people, and in our judgment it gets worse. The license bill shrinks with headcount. The second site, the 24-hour patching and the people who know how to run Exchange don't.
The outages nobody reports
There's a bias in how these mornings feel. When Microsoft 365 degrades, it's on the news and every customer hears about it at once. When a company's own mail server is down for a day because a disk controller failed or a certificate expired, nobody outside the building knows.
In-house also means the security work is yours. In March 2021 attackers exploited four previously unknown vulnerabilities in on-premises Exchange Server. Organizations running their own servers had to patch immediately and then work out whether they'd already been broken into. Exchange wasn't affected.
The Reddit poster made more point, and it may be the strongest. Almost everyone you correspond with is on Microsoft 365 or Google Workspace. If your own mail server had been perfectly healthy this morning, a good part of what you sent would still have been going to people who couldn't open their mailboxes.
What to do instead
Plan for Microsoft 365 being unavailable now and then, the way you'd plan for a typhoon closing the trains. A few hours is survivable if you've thought about it beforehand.
- Agree on a channel that doesn't depend on Microsoft. A phone tree, or a group on some other messaging service, set up and tested before you need it. Staff should know where to look when Teams and Outlook are both down.
- Make sure more than person can see Service health. Give a second person an admin role that includes it, have both install the Microsoft 365 Admin app, and turn on its notifications. If the admin center itself is unreachable, fall back to status.cloud.microsoft.
- Keep work available offline. Outlook's cached mode and OneDrive's synced folders let people read mail they already have and keep editing local copies of files.
- Hold your own copy of the data. A backup of Microsoft 365 with another provider doesn't shorten an outage, but it means the copy of your mail and files isn't inside the service that's down.
- Read the post-incident report. For an incident this broad, Microsoft commits to a preliminary review within 48 hours of resolution and a final within five business days. It appears in Service health under the incident ID, and it tells you whether the fix addresses the cause.
None of this lets Microsoft off the hook. We'll keep recommending Microsoft 365 over running your own, because the alternative costs more and fails more quietly. We'll also keep saying, to Microsoft and to clients, that a morning like this shouldn't happen.
If you'd like help preparing your Japan office for the next one, see our Microsoft 365 services or get in touch.
About the Author
Rick Cogley is CEO and Co-Founder of eSolia Inc., a bilingual IT management firm based in Tokyo. Since 1999, eSolia has provided B2B IT services to international companies operating in Japan, bridging Japanese business culture and international IT standards.