Monitoring Benefit
This is the Microsoft Entra row of Service Level Availability. It reports what proportion of the selected period Entra ID authentication was available, as measured by the sign-in test ENow runs against your tenant.
Entra deserves attention out of proportion to its single row, because everything else depends on it. If authentication fails, Exchange Online, Teams, OneDrive and SharePoint fail with it. When several workloads dip in the same window, this is the first row to read.
For how the figure is calculated, the two surfaces it appears on, the Node Type filter and where the thresholds live, see Configuration - Service Level Availability.
What feeds this figure
Entra availability is measured by a single test, which appears in the report's detail grid as AzureADAuthentication. It answers one question: can the test account authenticate against Entra ID from this node, right now.
That narrowness is deliberate and worth understanding. Directory synchronisation and password hash sync have their own indicators and are not part of this percentage. Those failures do not look like an outage — sign-in keeps working while identities quietly drift out of step. So this figure can sit at nearly 100% while new starters are missing and leavers are still active.
Use this row for can people sign in, and the Microsoft Entra Connect Directory Synchronization and Password Hash Sync checks for whether the directory is correct.
Read this row first when several workloads dip
| What you see | What it means |
|---|---|
| Entra down, other workloads down in the same window | Authentication is the cause. Work this row; the others are symptoms. |
| Entra healthy, one other workload down | Not authentication. The problem is in that workload itself. |
| Entra down, everything else healthy | Users already signed in keep working. Expect impact to widen as tokens expire. |
| Failures confined to one Site | That location's path to Entra, not Entra. Filter by Node Type to confirm. |
What the error detail tells you
Expanding the row shows the error returned by each failed attempt, and the distinction that matters most is visible there:
- A timeout, with a very high Elapsed Milliseconds value, means the request never completed — a network or endpoint reachability problem.
- A rejection that returns quickly means Entra answered and refused — credentials, Conditional Access, or the account state.
Those two look identical in the uptime percentage and lead to completely different investigations.
Common warning or error results, and potential solutions
| Result | Potential solution |
|---|---|
| Sustained 0% uptime | Usually the test account rather than the service — blocked, expired, or newly subject to MFA. Confirm it can sign in by hand. |
| Failures begin after a Conditional Access change | A policy is catching the monitoring account or its location. See Configuring Named Locations and Trusted IPs to Allow ENow External Monitoring. |
| Failures begin after a password change | The stored credential no longer matches. Update it wherever the monitoring account's password is held. |
| Every workload dips at once, including Entra | Treat as authentication or tenant connectivity, not five separate outages. |
| Uptime excellent but users report sign-in problems | The test uses one account from a few locations. A Conditional Access policy affecting a subset of real users will not appear here. |
For how Microsoft measures and reports its own SLA for Entra ID — a different measurement from this one — see Understanding Microsoft Entra ID SLA Performance.
Comments
0 comments
Article is closed for comments.