Why Do Microsoft 365, Teams and Exchange Go Down? Causes, How to Check, How to Prepare

Key takeaways

• Large cloud outages are most often caused by internal changes (configuration, deployment, routing) or by a failure in a shared dependency such as identity, DNS or a network front door.
• Do not assume an attack. Wait for the provider's post-incident review, and treat early speculation on social media as unverified.
• Your first source of truth is the Service health dashboard in the Microsoft 365 admin centre, which lists incidents by ID with status updates.
• Microsoft's standard service level for most Microsoft 365 services is 99.9 percent monthly uptime. That still allows about 43 minutes of downtime a month before service credits apply.
• Resilience is your job too: have an out-of-band communication plan, break-glass admin accounts and a tested outage runbook.

This page used to describe one specific outage with detailed claims about its date, scope and cause. Those details could not be verified, and the dates in the original were inconsistent, so they have been removed. What follows is more useful for a student or administrator: how Microsoft 365 outages happen in general, how to find the facts about a specific incident, and how to plan for the next one. If you are looking for a particular incident, use the official sources listed below and its post-incident review.

Why does Microsoft 365 go down?

Microsoft 365 is not one server. It is hundreds of services, Teams, Exchange Online, SharePoint, Entra ID for sign-in and more, spread over many data centres and linked by shared networking and identity layers. Most big outages have one of these causes.

The common thread is that scale amplifies mistakes. One bad change reaching millions of users at once is why cloud providers use staged rollouts and fast rollbacks, and why some outages still get through.

Was it a cyberattack?

Usually not. When Microsoft, or any large provider, publishes a root-cause analysis, most major outages turn out to be internal faults. But a few things apply every time:

• Early social media speculation about attacks is usually wrong, and it spreads faster than facts.
• A provider's statement about cause is the best evidence available, and it normally arrives days after the incident in a post-incident review, not during it.
• Past security incidents at the same vendor, such as the 2021 Exchange Server vulnerabilities, are about on-premises products and are separate from cloud outages. For that story see our article on the Microsoft server hack.

Attackers do exploit outages in a different way, with phishing emails pretending to be "recovery links" or support messages. Warn your users about this whenever an outage is in the news.

How to find out what really happened

1. Service health in the admin centre. Admins can open the Microsoft 365 admin centre, go to Health, then Service health. Incidents are listed with IDs (for example, ones starting with letters for the service, such as Exchange or Teams) and regular updates with status and impact.
2. Microsoft 365 Status on social media. Microsoft posts short updates for broad incidents on its official status account. Use only the official account.
3. The post-incident review. For significant incidents, Microsoft publishes a review with a timeline and root cause. This is the source to cite. Look for it through the Microsoft 365 admin centre and Microsoft's official service documentation on Microsoft Learn.
4. Your own tests. Sign in from a different network and device, and use the Microsoft Remote Connectivity Analyzer to check whether the problem is with you or with Microsoft.

Is it Microsoft or is it you?

Before you declare an outage, rule out local causes. Many "Teams is down" tickets turn out to be a local issue.

• Check whether others in the same office, and in other offices, are affected. A single-site problem points to your network, proxy or firewall.
• Test from a phone on mobile data. If it works, the fault is probably your network or DNS.
• Resolve the service names from an affected machine, for example nslookup outlook.office365.com, and compare with a working network.
• Check the Service health dashboard for an open incident that matches your symptoms and region.
• Look at sign-in failures. If only authentication fails, the identity service is the likely suspect.

What the service level really promises

Microsoft's financially backed service level for most Microsoft 365 services is 99.9 percent monthly uptime. Over a 30-day month (43,200 minutes), 0.1 percent is about 43 minutes. Beyond that, customers can claim service credits, which are a small refund, not compensation for lost work. Check the current service level agreement on Microsoft's licensing pages for exact terms. This is a reason to plan for failure instead of treating the SLA as a guarantee.

How to prepare your organisation for the next outage

1. Have an out-of-band way to reach staff. If email and Teams fail, how do you tell people? Keep a phone tree, an SMS or messaging group, and a status page on infrastructure that does not depend on Microsoft 365.
2. Keep break-glass admin accounts. Create two emergency accounts with strong credentials, exempt from conditional access rules that could lock everyone out, stored securely and monitored for any use.
3. Know your dependencies. List what relies on Microsoft 365: sign-in to other apps, ticketing, approvals, meetings, calendars. Single sign-on through Entra ID means an identity outage can hit apps that are not Microsoft's.
4. Keep offline copies of what you cannot lose. Contact lists, runbooks and key documents should be reachable without cloud access.
5. Write and rehearse an outage runbook. Who decides it is a vendor outage? Who informs staff and customers? What manual workarounds exist for critical processes?
6. Back up Microsoft 365 data. Microsoft provides availability and retention features, but it works on a shared-responsibility model, so independent backup of mailboxes and files is your decision.
7. Monitor proactively. Turn on Service health email notifications for admins, and add synthetic checks that sign in and send a test message so you notice before users do.

Lessons for students and junior engineers

• Read incident reviews. They are free lessons in how large systems fail, and they show how good teams describe cause, impact and fixes.
• Separate facts from guesses. Say "the provider reports X" and "we have not confirmed Y".
• Design for failure of dependencies you do not control: timeouts, retries with backoff, and fallbacks.
• Staged rollouts, feature flags and fast rollback are not optional for systems at scale.

Next steps

Write down your own organisation's outage plan this week, even if it is half a page. If you want to learn to administer the cloud side, the AZ-104 Microsoft Azure Administrator course covers identity, monitoring and resilience. For related reading on infrastructure incidents, see whether a power outage was a cyberattack.