KQL · availability
Availability test failures with their messages
List failed availability test runs from the last 24 hours with test name, location, duration and failure message, newest first.
availabilityResults availability
let lookback = 24h;
availabilityResults
| where timestamp > ago(lookback)
| where tostring(success) in~ ("false", "0")
| project timestamp, name, location, duration, message, operation_Id
| top 100 by timestamp descReturns: Up to 100 failed availability test runs from the last 24 hours, newest first, each with the test name, location, duration in milliseconds, failure message and operation_Id.
Pitfalls
- message is what the test engine wrote about the failure, such as a status code mismatch, a timeout or a content match failure. Group by it before reading rows one by one.
- A failure at one location among many passing ones is usually the network near that location. Look at the location column before treating a row as an outage.
- With retries on, each failed row is a run that failed three successive attempts at that location.
- This lists runs, so itemCount isn't needed; counting them would use sum(itemCount), as in the variation below.
How it works
When an availability alert fires, the first thing you want is the failure itself: which test, from where, and what it said. This query lists the failed runs with their messages, newest first, which is usually enough to tell a real outage from a test that needs fixing.
Line by line
let lookback = 24h;sets the window.where tostring(success) in~ ("false", "0")keeps failed runs. The classic schema typessuccessas a string; accepting both spellings makes the filter work whichever form the results use.projectkeeps the columns that explain a failure.nameis the test,locationis the test location that ran it,durationis how long the run took in milliseconds, andmessageis the failure description.operation_Idlinks the run to anything else recorded in the same operation.top 100 by timestamp desckeeps the latest 100 failures.
Reading the result
Read message and duration together. A duration that matches the test’s timeout means the app didn’t answer in time. A short duration with a status code message means the app answered with the wrong code. Messages about the certificate come from standard tests’ TLS checks. Failures on every location at the same minutes are an outage; failures on one location are usually the path to it, and Microsoft’s alert guidance (alert when several locations fail) exists for exactly that reason.
Availability tests can be correlated with server-side telemetry collected while handling the test’s request, which Microsoft calls out for diagnosing failures. Paste an operation_Id into the end-to-end trace query to see the request and dependencies the test triggered, if your app recorded them.
Grouping failures
When the list is long, count by message first:
let lookback = 24h;
availabilityResults
| where timestamp > ago(lookback)
| where tostring(success) in~ ("false", "0")
| summarize failures = sum(itemCount), locations = dcount(location), last_seen = max(timestamp) by name, message
| order by failures descFor success rates per location, see availability results by test and location. The alerts guide and the certificate expiration guide cover alerting on these failures and on certificates before they expire.
Variations
- Workspace tables: use
AppAvailabilityResults,TimeGenerated,Name,Location,DurationMs,Message,OperationIdandSuccess.