availability test
What it is
An Application Insights availability test is a recurring request that Azure sends to an application endpoint from selected test locations. It measures whether the endpoint responds as expected and how long that response takes. This is called synthetic monitoring because a test agent acts like a user rather than waiting for a real user to report trouble.
Think of a shop’s automatic door being tried from several streets on a schedule. It tells the owner whether people can get in from outside; it does not reveal every problem once they are inside the shop.
Why it exists
An application can be running while customers still cannot reach it because of DNS, certificate, routing, or web-server problems. Availability tests find this outside-in failure before a support ticket arrives.
Key ideas
- A current standard test sends an HTTP or HTTPS request to a publicly reachable endpoint. It can check response time, expected status, response content, and TLS certificate validity.
- Choose several test locations. A single failed location might be a local network problem; multiple failing locations make an application problem more likely.
- A failed request can be retried. With retries enabled, the test reports a failure only after three successive failed attempts at that location.
- The endpoint must be reachable by the test. A private-only endpoint needs a suitable internal health signal and metric or log alert instead of assuming a public availability test can reach it.
- A test produces monitoring data. An alert rule decides when that data represents a problem, and an action group defines who or what responds.
Northwind example
Northwind tests its public grocery ordering page from five locations every few minutes. The test expects an HTTPS response and a small “ordering available” text marker. Luis configures an alert only when several locations report failures, which reduces noise from a single location’s network problem. During planned maintenance, the team temporarily disables or adjusts the alert rule, then confirms the test passes after the release.
What it can and cannot prove
| A passing test supports | A passing test does not prove |
|---|---|
| The selected public endpoint answered the configured request from the tested locations. | Every signed-in customer journey, database operation, private endpoint, or business process works. |
Use availability tests together with server telemetry, dependency monitoring, and realistic application tests.
Common confusion
- A test is not an alert. It collects evidence; a rule evaluates that evidence.
- A 200 response alone may be too weak. Add a meaningful content check or a dedicated health endpoint, but do not expose sensitive details through it.
- Availability tests create external requests. Configure headers, firewall access, and endpoint behavior deliberately.
Related
application-insights · azure-monitor · alert-rule · action-group · tls · northwind-traders-case-study
Sources and re-audit
- Microsoft Learn — Application Insights availability tests, checked 2026-09-16.