Outlook outage: how to tell if it's Microsoft or you, and what to do next

Is Outlook down right now? A 60-second triage

Nearly every Outlook outage starts the same way: mail stops flowing, and nobody can tell whether Microsoft broke something or you did. Answer that question first. Everything else — support tickets, reinstalls, password resets, angry Slack messages — is wasted effort until you know which side the fault is on.

Check these four sources, in this order. They are ranked by how authoritative they are and how fast they react, which are not the same thing.

The practical rule: Downdetector tells you something is wrong, the admin center tells you what. If you have admin access, skip straight to Service health and search for an active incident. If you do not, a Downdetector spike plus a post on the status account is enough to stop troubleshooting your own laptop.

Why the Microsoft 365 status page can say 'healthy' while Outlook is broken

This is the single most confusing part of a live outage, and it catches people every time. During the Exchange Online incident that began on 31 August 2026, the public status page still listed Microsoft services as operational while the official Microsoft 365 Status account on X had already confirmed degraded Exchange Online functionality and pointed admins to incident EX1464935. Thousands of Downdetector reports were in by then.

That gap is structural, not a bug:

• The public page and the admin center are different systems. Service health in the admin center is tenant-scoped and driven by Microsoft's internal incident tracking. The public page is a summary product, updated on a slower editorial cadence.
• A tenant-scoped incident may never reach the public page at all. If an incident hits a subset of forests, regions or protocols, Microsoft will post it as an EX or MO advisory without ever turning the consumer status page amber.
• Incidents get re-scoped mid-flight. The 31 August incident opened as an Exchange Online problem under EX1464935, then was re-tracked under MO1465074 once Microsoft confirmed it also touched OneDrive for Business, SharePoint Online, Teams, Purview and Defender XDR. If you were watching only the Exchange entry, you saw half the outage.

So when someone tells you "Microsoft says everything is fine", ask which page they looked at. A green public status page is not evidence that the problem is on your side.

How to tell an Outlook outage from a problem on your side

If there is no confirmed incident, you need to prove it locally. The goal is to change one variable at a time until you isolate the failing layer: account, client, device, or network.

1. Open Outlook on the web in a private window. If webmail works and the desktop client does not, the service is up and the problem is your client profile, cached credentials, or an add-in.
2. Try a second account on the same device. Works for one account and not the other → the fault is mailbox- or identity-scoped, not service-wide.
3. Try the same account on a different network. Phone hotspot instead of office Wi-Fi. This separates DNS, proxy and firewall problems from Microsoft's side, and it catches the surprisingly common case where a security appliance update broke TLS inspection for Exchange endpoints.
4. Run Microsoft's Remote Connectivity Analyzer. It tests Exchange connectivity from outside your network, so a pass here plus a local failure points squarely at your environment.
5. Check whether it is authentication rather than mail. Several of 2026's larger incidents were authentication faults, not mail-flow faults. If sign-in fails but an already-authenticated session still loads mail, you are looking at an identity problem.

One diagnostic that saves real time: ask whether the failure is uniform. A genuine service outage tends to hit everyone in a tenant at once and hit multiple clients equally — desktop, web, and mobile. A problem that affects one user, one device, or only one protocol is almost never Microsoft.

How long Outlook outages actually last

Long enough to matter, short enough that a panicked migration is the wrong response. Here is the 2026 record for the major Microsoft 365 incidents that took Outlook or Exchange Online with them:

Two patterns are worth internalising. First, most of these were configuration or maintenance faults, not capacity faults — which is why they resolve by rollback rather than by scaling, and why they tend to end in hours rather than days. Second, authentication is the common blast radius. When identity breaks, it takes email, files and chat with it, so planning that assumes "email is down but Teams still works" is planning for the rarer case.

What to do while Outlook is down

Once you have confirmed a real incident, stop troubleshooting. Repeated profile rebuilds and password resets during an outage generate their own problems — and a wave of resets during an authentication incident can leave you cleaning up long after Microsoft has recovered.

If you are a user

• Try Outlook on the web and Outlook mobile before assuming total failure. Incidents frequently hit one protocol or one client path.
• If Outlook desktop is in Cached Exchange Mode, you can still read and search existing mail, and draft messages that queue in Outbox and send on recovery. Do not delete anything from Outbox while queued.
• Assume delayed rather than lost mail. Messages that fail during an Exchange incident are usually queued upstream and delivered late, sometimes in a large burst at recovery.

If you run IT

• Post the incident ID internally within the first ten minutes. It shuts down the ticket flood better than any status update, and it gives you a reference for the postmortem.
• Communicate on a channel that does not depend on the broken service. If the incident scope includes Teams, your Teams announcement is not going to land.
• Watch for improvised workarounds. This is the real risk. Under pressure, staff move invoices, contracts, bank details and credentials to personal email accounts and consumer messaging apps to keep work moving. That creates a data-handling problem that outlives the outage by months. Say explicitly what people may and may not do while mail is down.
• Log actions with timestamps as you go. Anything you defer to "after it's fixed" gets forgotten.

When an Outlook outage breaks your systems, not just your inbox

For most businesses the expensive part of a Microsoft 365 outage is not people unable to read email. It is the machinery that quietly sends mail on your behalf: order confirmations, password resets, invoices, appointment reminders, alerts from your own monitoring. If those go through smtp.office365.com or Microsoft Graph, they fail exactly when Exchange fails.

The failure mode that costs money is not the outage itself, it is what your application does about it. Three patterns cause almost all of the damage:

None of this is exotic engineering. A durable queue, bounded retries with backoff, a dead-letter path you actually look at, and one alternate relay covers the majority of the risk. The reason it is so often missing is that email sending gets built early, in a hurry, by whoever was closest — and never revisited. If your outbound mail path is a single send_mail() call in a request handler, that is worth fixing before the next incident rather than during it; it is the kind of thing we tend to find first when we build or take over a business system.

Get outage alerts before your users tell you

Refreshing a status page is not monitoring. Microsoft exposes tenant service health through the Microsoft Graph service communications API, so you can pull incidents into your own alerting rather than waiting for someone to complain.

The two calls that matter, both documented in Microsoft's service communications API reference:

# All current service health issues for your tenant
GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/issues

# Health of one service, with its open issues expanded
GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/healthOverviews/Exchange%20Online?$expand=issues

Both need the ServiceHealth.Read.All permission, delegated or application. A response carries the incident id (the EX or MO number), a classification of advisory or incident, a status such as serviceDegradation or serviceRestored, and the rolling update posts.

A worthwhile setup takes an afternoon:

• Poll /issues every few minutes with an app-only token, and cache by incident ID so you alert on new incidents and on status transitions, not on every poll. Back off on 429 — the service communications endpoints do throttle.
• Filter to the services you actually depend on. A Purview advisory does not need to wake anyone.
• Push to a channel that does not run on Microsoft 365. An incident that takes Teams down should not be announced in Teams.
• Pair it with a synthetic check of your own: send a message through your production mail path every few minutes and alert on failure. That catches the incidents Microsoft has not admitted yet, which is most of them for the first half hour.

If your stack also depends on an AI provider, the same reasoning applies there — see our companion piece on telling a ChatGPT outage apart from your own problem.

The part of an Outlook outage you can actually control

You cannot make Microsoft's authentication infrastructure more reliable, and switching email providers over an annual multi-hour incident is almost always a worse trade than it looks. What you can control is the blast radius on your side.

Three things separate an organisation that shrugs off an Outlook outage from one that loses a day to it:

1. You find out from a system, not a user. Service health polling plus a synthetic send.
2. Your applications degrade instead of failing. Queued mail with retries, so an outage produces late email rather than lost orders.
3. Your people know the rules in advance. Which channel to use, what may not be moved to personal accounts, who posts the incident ID.

The first two are engineering work, and they are small — usually days, not weeks. If email, alerting or integrations sit on a single unmonitored path in your product, that is the gap to close. Tell us what your stack looks like and we will tell you where it breaks next time.