Configuration - Service Level Availability - Microsoft Teams

Monitoring Benefit

This is the Microsoft Teams row of Service Level Availability. It reports what proportion of the selected period Teams was available, as measured by the messaging test ENow runs against your tenant.

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

Teams availability is measured by a single test, which appears in the report's detail grid as MicrosoftTeamsMessaging. It sends a message and confirms it was accepted.

Everything else Teams-related is measured separately. Calendar Integration, Online Meeting, Internal User Search and the call quality pages all have their own indicators and are not part of this percentage. That makes this row narrower than most people assume when they see "Teams" on an availability report.

Availability is not call quality — and this row proves it

A messaging test says the service accepted a message. It says nothing about whether a meeting sounded acceptable. This is the single most common misreading of this row:

What the failures usually look like

Expand the row and the error detail tends to fall into two groups, and they need different responses:

• Timeouts and cancelled requests, with very high Elapsed Milliseconds — the request never completed. Network path, proxy, or an inspection device between that node and Microsoft.
• An outright send failure returning quickly — Teams answered and refused. Look at the test account, its licence, and any messaging policy applied to it.

Both count identically against uptime, so the percentage alone will not tell you which you had.

Common warning or error results, and potential solutions