Microsoft 365 Service health is the first place to check when users report a Microsoft 365 outage. In the Microsoft 365 admin center, it lists the incidents and advisories Microsoft is working on for your tenant, service by service. It answers one question well: does Microsoft have an incident? Where your own users are stuck is a second question.
The call usually arrives as "Teams is not working". Before anyone restarts a router or opens a case with Microsoft, the helpdesk needs to know which side the problem sits on. This article covers what Service health shows, a triage checklist, and what continuous Microsoft 365 monitoring adds when you need to know who is affected, where and for how long.
What does Microsoft 365 Service health show?
Service health shows the incidents and advisories Microsoft is working on for your tenant, service by service, plus a section of issues detected in your own environment that your organisation needs to act on. Many admins still call it the Office 365 service health dashboard. It sits under Health in the Microsoft 365 admin center, and helpdesk admins can read it too (How to check Microsoft 365 service health).
Each post gives an ID, the affected services, the estimated start time, the user impact and a feed of updates. A field called Issue origin indicates whether the issue was found at Microsoft or in your environment. Microsoft also separates two kinds of post:
- Advisory: some users are affected, but the service still works.
- Incident: the service, or a major part of it, is down.
Microsoft updates an active incident every hour, unless the post states another cadence. For broad incidents, Microsoft publishes a preliminary post-incident review within 48 hours of resolution and a final one within five business days (Service health and continuity).
What is Service health not designed to answer?
Service health answers "does Microsoft have an incident?", not "why can this user not work right now?". That is not a flaw: it follows from what Service health reports.
- An issue only appears once Microsoft has identified it. Microsoft's service description gives no time for this.
- Some problems are not service incidents. By Microsoft's own definition, problems caused by third-party providers or by changes in your own environment are not service incidents. An ISP fault or a change to your VPN or federation set-up is not one.
A quiet Service health page is therefore useful information: Microsoft has no identified incident for your tenant yet. Start looking on your side, and keep the page open.
Which signal answers which question during a Microsoft 365 outage
Each signal is designed for one question.
| Signal | What it tells you | What it cannot tell you |
|---|---|---|
| Service health (admin center) | The incidents and advisories Microsoft is working on for your tenant, with affected services, user impact and regular updates, plus issues detected in your environment that need your action. | An issue Microsoft has not identified yet. Problems caused by third-party providers or by changes in your own environment are not service incidents by Microsoft's definition, so do not expect to find them as one. |
| Public status page (status.cloud.microsoft) | Known sign-in issues, when you cannot sign in to the admin center. | The detail of your tenant's incidents, which stays in Service health. |
| @MSFT365Status on X | Microsoft's posts on certain events. | A complete list of incidents, or anything specific to your tenant. |
| Network connectivity (admin center) | How well each declared or discovered office location connects to Microsoft 365. | One person's connection: remote workers are reported by city, not by person. |
| A colleague at the next desk | Whether the same service works for someone else in the same place. | Which layer differs for the affected user: device, session, Wi-Fi or network path. |
| Experience monitoring set up for your tenant | Which users, sites, functions and platforms are affected, and on which layer. | Devices without the agent, and locations without a probe. |
How do you tell a Microsoft 365 outage from a local problem?
Start with who is affected, then Microsoft's signals, then the path of one affected user. Each step either confirms a Microsoft incident or narrows the search on your side.
- Ask who else is affected, and since when. "It works for my neighbour" is a useful answer. The service is answering, so look at what differs for this user: the device, the Wi-Fi, the network path or the session. It usually points to a local cause, though a Microsoft sign-in problem can also spare people who are already signed in.
- Open Service health. Look for an active incident or advisory on the service concerned, with its user impact and estimated start time. Check the issues for your organisation to act on as well.
- No admin center? Use the public status page. If you cannot sign in to the admin center, Microsoft's public status page at status.cloud.microsoft shows known sign-in issues.
- Report what Microsoft has not posted. If an issue is missing, admins can report it from Service health, and Microsoft checks whether other organisations see it too. Follow it under Reported issues.
- Rule out planned work. Check Message center for maintenance on the service, and your own change log for anything that touched sign-in, DNS, the proxy or the VPN.
- Check the office. If your office locations are declared or discovered in the admin center, it also scores network connectivity for each one. A low score for the affected office points to that site's connection rather than to the service.
- Walk the path for one affected user. Device, local network, ISP, VPN, corporate network, sign-in (often federated through AD FS or a third-party identity provider), then the service itself. Compare each step with a colleague who is not affected.
- Tell users what you know. Say whether the cause looks internal or sits with Microsoft, and when the next update will come. Once Microsoft has posted, its updates, hourly unless the post states another cadence, set the pace for yours.
Without measurements, steps 1, 6 and 7 depend on asking users and testing by hand, which is where continuous monitoring helps most.
What we see in the field
Over 15 years of monitoring projects with large enterprises, the pattern has not changed: IT hears about an incident last. Users notice that something "does not work for me", sometimes while it works for the person at the next desk, and the helpdesk is told far too late.
The cloud has added a reflex: blame Microsoft. In our experience, around nine in ten of the incidents users notice start inside the organisation's own perimeter, not at Microsoft. The "it must be Microsoft" reflex costs time when the cause sits in federated authentication, the VPN, the ISP or the device.
There are many layers between a user and the service, and each one can fail:
- The device and its resources
- The local network and Wi-Fi
- The headset, certified or not, and how it is connected
- The ISP
- The VPN to the offices, or no VPN at all
- A hub-and-spoke architecture, with people, resources and offices spread across sites
- Microsoft's network, stable in principle
- Access to internal resources
- Authentication: identities in Microsoft Entra ID, often federated with AD FS or a third-party identity provider
- Then the services themselves: Teams, SharePoint, Exchange, OneDrive and the rest
When the cause really is at Microsoft, timing becomes the issue. In incidents we have followed, the advisory often appeared well after users were already affected. Service health is still the right first check: it answers whether Microsoft has an incident, not whether your users are affected. Many organisations fill that gap by watching Microsoft's status account on X or public outage reporting sites. Those signals are declarative and collective: they say that something is wrong somewhere, not whether your own users are affected.
One case shows the difference. During a Microsoft outage linked to DNS and authentication, users who already held a valid authentication token, or a cached DNS answer, kept working. New sessions failed. It worked for some people and not for others, and public signals were ambiguous. An experience monitoring tool configured for that tenant picked it up straight away, because its end-to-end sign-in tests started failing.
Our conclusion: only monitoring configured for your own tenant can alert at the right time, with the right severity, for the users you actually have.
What does continuous monitoring add to Service health?
Continuous monitoring measures what your users get, from their own devices and sites. Service health stays the reference for what Microsoft is working on; monitoring adds your side of the picture.
Microsoft already applies the same idea: its Exchange Online monitoring uses synthetic connections from your devices (Exchange Online monitoring for Microsoft 365). Experience monitoring extends that approach to the services and sites you choose, with two methods:
- Synthetic tests repeat everyday actions, such as signing in, posting in a Teams channel or sending a mail, from the sites you choose, around the clock. A sign-in that fails at 07:00 can raise an alert before the first user arrives.
- Real user monitoring measures each workload on each device while people work, and compares it with each user's own baseline.
Both methods are compared in our article on SharePoint Online monitoring with synthetic tests and real user data. For calls, the same logic applies to Teams and Zoom call quality monitoring.
The Microsoft Graph service communications API lets monitoring tools read Service health and Message center posts (service communications APIs in Microsoft Graph). The incident Microsoft has posted and the impact you measure can then sit side by side.
How Neptune helps
Neptune is an integrator. We select the monitoring tools that fit your estate, implement them in your tenant with your team, train your helpdesk and network teams to read them, and support you during the project, then through a customer success manager. The tools we put in place answer the questions above:
- Is Microsoft 365 working from each site? Virtual users test Microsoft 365 from each site, around the clock, repeating everyday actions such as posting in a Teams channel or sending a mail, and raise an alert when a service slows down.
- Where does the cause sit? Probes in each office show which group of users is affected and whether the cause sits with Microsoft or on your side. Each layer, from the device to Microsoft, is measured on its own, so an issue goes straight to the team or provider that owns it.
- Who does a Microsoft incident really affect? When Microsoft posts an incident, it is matched to the users it really hits in your organisation: who, at which site and for how long, with a report kept for afterwards. The view shows which service, function and platform is affected, so people can be pointed to a version that still works.
- Is this user's experience normal? Each workload gets an experience score measured against that person's own normal, so a sudden drop stands out from a long-standing problem.
- Is sign-in at risk on our side? Hybrid components such as AD FS, pass-through authentication and Exchange hybrid are watched, with a warning before certificates expire.
We agree with you which sites, services and user groups to watch first, and set alert thresholds and recipients with your helpdesk, network and NOC teams. See how we approach service availability and outage impact in our monitoring offer. If you still run Exchange Server, our Exchange monitoring page and our guide to moving to Exchange Server Subscription Edition cover the on-premises side.
Sources
- How to check Microsoft 365 service health
- Service health and continuity
- Network connectivity in the Microsoft 365 Admin Center
- Exchange Online monitoring for Microsoft 365
- Working with service communications APIs in Microsoft Graph
- About the Microsoft 365 admin mobile app
- Microsoft service health status (public page)
