Overview
The Service Health monitoring test appears in the Microsoft 365 section of the monitoring console.
Monitoring Benefit
The Service Health test surfaces the status Microsoft publishes on the Microsoft 365 Service Health dashboard, presented in the ENow console alongside the rest of your environment, together with the update posts Microsoft adds to an incident as it progresses.
The value is not that it detects anything Microsoft has not — it is that you stop having to watch two places. A Microsoft-side incident shows up next to your own on-premises and hybrid indicators, so when something breaks you can tell at a glance whether it is yours to fix.
This test relays Microsoft's own reporting. It does not independently probe the service. That distinction matters in both directions, and it is the single most useful thing to understand about this indicator:
- If Microsoft has not declared an incident, this indicator stays green — even when your users are affected. A green Service Health indicator is not evidence that a workload is healthy for you.
- If this indicator turns, Microsoft has declared something. That is a reliable signal, but it usually arrives after your users have noticed.
For that reason, treat Service Health as corroboration rather than detection. ENow's synthetic transaction tests are what tell you whether a workload is working for your tenant; Service Health tells you whether Microsoft agrees there is a problem, and what they are saying about it.
How do we verify the monitoring test results?
1. Compare against the source. The status shown here comes from the Microsoft 365 admin center. Sign in and open Health > Service health to see the same incidents Microsoft is reporting for your tenant. The two should agree; if they do not, the collection has not refreshed yet.
2. Read the update posts. Microsoft adds updates to an incident as it progresses, and those updates carry the detail — which workloads and regions are affected, whether mitigation is underway, and the expected timeline. The indicator alone only tells you an incident exists.
3. Check whether the incident actually affects you. Service health incidents are scoped to particular services and often to particular regions or infrastructure. An incident being reported does not always mean your users are among those impacted.
4. Corroborate with your own tests. Where a Microsoft incident is declared, the ENow synthetic transaction tests for that workload show whether it is actually degraded for your tenant. Where users are complaining and Service Health is green, trust the synthetic tests — Microsoft has not declared anything yet.
Getting an alert when Microsoft declares an incident
Whether you are emailed about Microsoft service incidents is set in Alert Delivery, not on this test:
- In the ENow web console, go to Settings > Alert Settings > Alert Delivery > Microsoft 365.
- Scroll to the Microsoft 365 Configuration Service Health row.
- Set its delivery preference to Alert on all, and choose the email policy that should receive it.
- Save.
If this row is set to alert on critical only, you are emailed only when the status goes critical. Set it to Alert on all if you want to hear about Microsoft outages and service degradations generally.
What the alert email contains. The email tells you the Service Health status changed. It does not include Microsoft's incident text or the update posts. Open this test in the console, or Health > Service health in the Microsoft 365 admin center, to read them. Including the incident detail in the alert has been logged as a product idea; to add your vote, see Submit a New Product Idea in Aha.
Common warning or error results, and potential solutions
| Result | Potential solution |
| An incident is being reported | Read the update posts for scope and expected timeline, then confirm against your own synthetic transaction results whether your tenant is affected. There is no action to take against Microsoft's infrastructure; the value is in knowing the cause is not yours. |
| Users report problems but Service Health is green | Expected, and not a fault in the test. Microsoft has not declared an incident. Investigate using the synthetic transaction tests for that workload rather than waiting for this indicator to turn. |
| Service Health shows an incident that does not match user experience | Incidents are scoped by service and often by region. Read the update posts to establish whether your tenant falls inside the declared scope. |
| Status appears stale compared with the admin center | Compare directly against Health > Service health in the Microsoft 365 admin center and allow a collection cycle to complete. |
| No data returned at all | The collection could not reach Microsoft. Confirm the Microsoft 365 monitoring credential is valid and that outbound connectivity from the monitoring node is intact. |
| An incident shows in the console but no email arrived | Check the Microsoft 365 Configuration Service Health row in Alert Delivery, as described above. |
Related
- Microsoft 365 Service Health and Continuity — background on how Microsoft classifies incidents, what a post-incident review contains, and the notification cadence Microsoft commits to.
- Understanding Email Configuration, Email Policies, and Alert Delivery in ENow — how Alert Delivery decides who receives which alert.
Comments
0 comments
Please sign in to leave a comment.