This chapter covers Application Insights Availability Tests, a feature that monitors the availability and responsiveness of your web applications from multiple global locations. For the AZ-204 exam, this topic falls under Domain 4: Monitor (Objective 4.1 – Monitor and analyze resource utilization and performance). Expect 5-10% of exam questions to touch on availability monitoring, including test types, configuration, alerting, and multi-step tests. Understanding the internals of these tests and common exam traps is critical to scoring well.
Jump to a section
Imagine you run a large office building with multiple entrances. You hire a security guard to periodically check each door to ensure it opens properly and the lock works. The guard doesn't just check once; he follows a schedule: every 5 minutes he visits a different door, tries to open it, and records whether it opens within 3 seconds. If a door sticks or takes longer than 3 seconds, he logs a 'slow response' alert. If the door is completely jammed, he logs a 'failure' and immediately calls the building manager. The guard also has a list of expected behaviors: for the main entrance, he expects a green light within 2 seconds; for the side door, he expects a click sound within 1 second. He compares actual results against these thresholds. At the end of each day, he compiles a report showing the percentage of successful checks and the response times. He also can send a test from different locations (e.g., from inside the building vs. outside) to simulate different user experiences. If the guard is unable to reach a door (e.g., blocked path), he logs a 'location unavailable' error. This is exactly how Application Insights Availability Tests work: they periodically ping your web endpoint from multiple Azure regions, measure response times against custom thresholds, and report success/failure along with detailed diagnostics.
What Are Application Insights Availability Tests?
Application Insights Availability Tests are synthetic monitoring probes that periodically check whether your web application is reachable and responsive from various geographic locations. They simulate user requests to validate that your endpoints are live and performing within acceptable thresholds. These tests are part of Azure Monitor's Application Insights, which collects telemetry from your application.
Why They Exist
Availability tests exist to detect outages, latency issues, and routing problems before they impact real users. They provide proactive alerts when an endpoint fails or degrades, enabling rapid response. For the exam, remember that availability tests are distinct from performance tests (e.g., load testing) – they are lightweight, frequent checks focused on uptime and response time.
How They Work Internally
Availability tests are executed by the Azure Availability Monitoring service, which runs from a set of globally distributed Azure data centers (test locations). The test flow: 1. A test agent in a selected Azure region sends an HTTP/HTTPS request to your endpoint URL. 2. The agent waits for a response, measuring the time until the first byte or full response (depending on test type). 3. The agent compares the response status code and response time against your defined success criteria. 4. If the criteria are met, the test is marked as 'passed'; otherwise, 'failed'. 5. Results are sent to your Application Insights resource, where they are aggregated and available in the Azure portal, Log Analytics, or via APIs. 6. Alerts can be triggered based on failure counts or response time thresholds.
Types of Availability Tests
There are three types of availability tests: - URL ping test (classic): Simple HTTP GET request. Validates status code (e.g., 200) and response time. Does not support TLS validation or parsing of response content. Note: This test type is deprecated in favor of Standard tests but still exists for backward compatibility. - Standard test (recommended): More advanced than URL ping. Supports:
Custom success criteria (status code range, response time threshold, content match).
SSL certificate validation (checks expiration date, chain, revocation).
Advanced options like follow redirects, parse dependent requests, and enable retries.
Multi-step web test (Visual Studio webtest format): Records a sequence of HTTP requests (e.g., login -> navigate -> submit form). Requires a Visual Studio 2017 or 2019 Enterprise edition to record the .webtest file. This test type is ideal for validating transactional scenarios.
Key Configuration Parameters
Test frequency: How often the test runs. Default: 5 minutes. Allowed values: 5, 10, 15, 30 minutes, or 1 hour.
Test locations: Up to 50 Azure regions (e.g., West US, East US, North Europe, Southeast Asia). You can select multiple locations to test global availability.
Success criteria:
- Status code: Acceptable HTTP status codes (e.g., 200, 201, 301-302). Default: 200. - Response time: Maximum acceptable time in milliseconds. Default: 5000 ms (5 seconds). - Content match: Optional string that must appear in the response body (e.g., "Welcome"). - Alert rules: You can set up metric alerts based on: - % of failed tests over a rolling window (e.g., 3 failures in 5 minutes). - Average response time exceeding threshold. - SSL certificate validation: For Standard tests, you can require valid certificates with a minimum remaining days (e.g., 30 days).
Test Execution and Results
Each test execution produces a result record containing:
- timestamp, location, success (boolean), duration (ms), statusCode, message (error details), sslCertExpiry (if applicable).
- Results are stored in the availabilityResults table in Log Analytics.
- Aggregated metrics: availabilityResults/availabilityPercentage, availabilityResults/duration.
Interaction with Related Technologies
Application Insights: Availability tests are a feature of Application Insights. You need an Application Insights resource to create and view tests.
Azure Monitor Alerts: Alerts can be configured to send email, SMS, webhook, or ITSM actions when availability drops.
Log Analytics: You can query availability results using Kusto Query Language (KQL) for advanced analysis.
Azure Dashboards: You can pin availability charts to custom dashboards for real-time visibility.
Configuration via Portal and CLI
In Azure portal: Application Insights -> Availability -> Create test. Choose test type, enter URL, set frequency, locations, success criteria, and alerts.
Using Azure CLI:
# Create a standard availability test
az monitor app-insights component availability-test create \
--resource-group MyResourceGroup \
--app-insights MyAppInsights \
--name MyAvailabilityTest \
--location westus \
--url "https://myapp.azurewebsites.net/health" \
--frequency 300 \
--enabled true \
--request-type GET \
--success-status-code 200 \
--timeout 5000Best Practices
Use multiple test locations to detect regional outages.
Set realistic response time thresholds based on your application's baseline.
For critical endpoints, use Standard tests with SSL validation and content matching.
Combine availability tests with synthetic transaction tests (multi-step) for end-to-end validation.
Set up alerts with actionable notifications (e.g., webhook to trigger auto-remediation).
Common Pitfalls
Not selecting enough locations: A single location may not detect regional issues.
Ignoring SSL certificate expiry: Standard tests can warn you before certificate expiration causes outages.
Setting too low response time threshold: May cause false positives due to network latency.
Using URL ping for complex scenarios: URL ping does not validate content or SSL; use Standard tests instead.
Exam-Relevant Details
The exam expects you to know the three test types and when to use each.
Remember that URL ping tests are deprecated; Standard tests are the recommended option.
Multi-step tests require a .webtest file created with Visual Studio Enterprise.
Test frequency minimum is 5 minutes; maximum is 1 hour.
You can select up to 50 test locations.
Default timeout is 5 seconds (5000 ms).
Alerts can be based on failure rate or response time.
Availability results are stored in the availabilityResults table.
KQL Query Example
availabilityResults
| where timestamp > ago(1h)
| where success == false
| project timestamp, location, duration, messageCreate Application Insights Resource
Before you can create availability tests, you must have an Application Insights resource in your Azure subscription. This resource collects and stores telemetry from your application, including availability test results. In the Azure portal, navigate to 'Application Insights' and click 'Create'. Provide a name, select the same resource group as your application (for easy management), and choose a region. The resource will generate an instrumentation key (ikey) used to authenticate telemetry. For the exam, remember that availability tests are tied to an Application Insights resource, not directly to a web app.
Configure Availability Test in Portal
In your Application Insights resource, go to the 'Availability' blade under 'Investigate'. Click 'Create test'. Choose the test type: Standard test is recommended. Enter the endpoint URL (e.g., https://yourdomain.com/health). Set the test frequency (default 5 minutes). Select at least two test locations from the list of Azure regions (e.g., West US and North Europe). Define success criteria: acceptable status codes (default 200), response time threshold (default 5000 ms), and optionally a content match string. Enable SSL certificate validation if needed. Click 'Create'.
Set Up Alert Rules
After creating the test, configure alerts to notify you when availability drops. In the same Availability blade, click 'Alerts' and then 'New alert rule'. Define the condition: e.g., 'Whenever the average availability percentage is less than 99% over 5 minutes'. Set the severity (e.g., Sev 1 for critical). Configure action groups: email your team, send SMS, or trigger a webhook to automate remediation (e.g., restart an Azure Web App). For the exam, know that you can create alerts based on metrics like 'availabilityResults/availabilityPercentage' and 'availabilityResults/duration'.
View and Analyze Results
Once the test runs, results appear in the Availability blade. You see a chart of availability percentage over time and a response time chart. Click on individual data points to see details: which location passed/failed, duration, and any error message. You can also query results using Log Analytics. For example, run a KQL query to list all failures in the last hour. Use the 'availabilityResults' table. This step is crucial for troubleshooting: if a test fails from one location but not others, it may indicate a regional issue.
Implement Multi-Step Web Test (Optional)
For complex scenarios (e.g., login + page navigation), you can create a multi-step web test. First, record the user flow using Visual Studio Enterprise (2017 or 2019) with the 'Web Performance Test' project. Export the test as a `.webtest` file. Then, in the Azure portal, create a new availability test and choose 'Multi-step web test'. Upload the `.webtest` file and configure frequency, locations, and alerts. Note: This test type is more expensive and less frequently used on the exam, but you should know it exists and its dependency on Visual Studio Enterprise.
Enterprise Scenario 1: Global E-Commerce Platform
A large e-commerce company with customers worldwide uses availability tests to monitor their production website from 10 Azure regions. They have a Standard test hitting https://www.example.com/health every 5 minutes from each region. Success criteria: status code 200 and response time < 2000 ms. They also have a content match for "OK" in the response body. Alerts are configured to notify the on-call engineer via PagerDuty if availability drops below 99.5% over 10 minutes. This setup helped them detect a DNS misconfiguration in the West US region within 2 minutes, preventing prolonged downtime. They also use multi-step tests to validate the checkout flow once per hour from two regions.
Enterprise Scenario 2: SaaS Provider with SLA Commitments
A SaaS provider offers 99.9% uptime SLA. They deploy availability tests from multiple locations to measure compliance. They set up Standard tests with SSL certificate validation (minimum 30 days before expiry) to avoid certificate-related outages. They also use test locations in the same Azure regions as their customers to simulate real user experience. Log Analytics queries generate monthly SLA reports. When a test fails, an automated runbook restarts the web app and logs the incident. Common issue: test failures due to network latency from a specific ISP, which required adjusting the response time threshold from 5000 ms to 8000 ms to reduce false positives.
Scenario 3: Internal Line-of-Business Application
A financial services company uses availability tests for internal applications hosted on Azure App Service. They create Standard tests that include header validation (e.g., X-API-Key in request headers) to ensure the app is properly authenticated. They also use content match to verify that the response contains "status":"healthy". Since the app is internal, they only test from a single Azure region (same region as the app) but increase frequency to every 5 minutes. Alerts send email to the IT team. A common problem: the app's health endpoint returns 200 even when the database is down. They fixed this by making the health endpoint check database connectivity and return 503 if unavailable, which the availability test detects as a failure.
Exactly What AZ-204 Tests
AZ-204 Domain 4 (Monitor) Objective 4.1: 'Monitor and analyze resource utilization and performance'. The exam specifically tests your ability to:
Implement availability tests (URL ping, Standard, multi-step)
Configure test locations, frequency, and success criteria
Set up alerts based on availability metrics
Interpret availability results and use Log Analytics
Understand the differences between test types and when to use each
Common Wrong Answers and Traps
Choosing URL ping test for content validation: Many candidates think URL ping can check response body content. Wrong – URL ping only checks status code and response time. Standard tests are needed for content matching.
Thinking multi-step tests can be created without Visual Studio Enterprise: The exam will test that recording a multi-step test requires Visual Studio Enterprise (not Community or Professional).
Assuming availability tests can be created for VMs or on-prem servers: Availability tests work for any HTTP/HTTPS endpoint, but the test agent runs from Azure regions. The endpoint must be accessible from the internet. If the endpoint is behind a firewall, you must allow the test agent IP ranges.
Confusing availability tests with Application Insights Profiler: Profiler traces performance of live requests; availability tests are synthetic probes. They are different features.
Selecting too few test locations: The exam may ask you to design a solution that detects regional outages – you need multiple locations.
Specific Numbers and Terms
Default test frequency: 5 minutes (300 seconds)
Default timeout: 5000 ms (5 seconds)
Max test locations: 50
Supported test types: URL ping (deprecated), Standard, Multi-step
Standard test supports: SSL validation, content match, follow redirects, parse dependent requests
Multi-step test file format: .webtest (Visual Studio Web Performance Test)
Alert metrics: availabilityResults/availabilityPercentage, availabilityResults/duration
Edge Cases
Test fails from one location but passes from others: Likely a regional network issue or routing problem. Not a global outage.
Test passes but users report issues: The test may not cover the same path (e.g., test hits a simple health endpoint, but users hit complex pages). Use multi-step tests for complex flows.
SSL certificate validation only available in Standard tests (not URL ping).
If you set content match, the test fails if the string is not found, even if status code is 200.
How to Eliminate Wrong Answers
If the question mentions 'content validation' or 'SSL certificate', eliminate URL ping test.
If the question mentions 'recorded user flow', eliminate Standard test – must be multi-step.
If the question asks for 'minimum frequency', answer 5 minutes.
If the question asks for 'maximum locations', answer 50.
If the question asks for 'tool to create multi-step test', answer Visual Studio Enterprise.
Availability tests are synthetic probes that check endpoint availability from multiple Azure regions.
There are three test types: URL ping (deprecated), Standard (recommended), and Multi-step (requires .webtest file from Visual Studio Enterprise).
Default test frequency is 5 minutes; minimum is 5 minutes, maximum is 1 hour.
You can select up to 50 test locations (Azure regions).
Default success criteria: status code 200, response time < 5000 ms.
Standard tests support content matching, SSL certificate validation, and follow redirects.
Multi-step tests are used for complex transactional scenarios (e.g., login, add to cart).
Alerts can be based on availability percentage or response time thresholds.
Availability results are stored in the 'availabilityResults' table in Log Analytics.
To detect regional outages, always configure tests from multiple locations.
These come up on the exam all the time. Here's how to tell them apart.
URL Ping Test
Deprecated test type
Only validates HTTP status code and response time
Does not support content matching
No SSL certificate validation
Cannot follow redirects or parse dependent requests
Standard Test
Recommended test type
Supports custom success criteria (status code range, response time, content match)
Supports SSL certificate validation (expiration, chain, revocation)
Can follow redirects and parse dependent requests (e.g., images, scripts)
Supports advanced options like retries and custom headers
Mistake
Availability tests can only be created for Azure App Service.
Correct
Availability tests can monitor any HTTP/HTTPS endpoint that is accessible from the internet, including on-premises servers, VMs, or other cloud providers.
Mistake
URL ping test is the best choice for most scenarios.
Correct
URL ping test is deprecated and lacks features like content matching, SSL validation, and follow redirects. Standard test is the recommended option.
Mistake
Multi-step web tests can be created using any version of Visual Studio.
Correct
Multi-step tests require Visual Studio Enterprise (2017 or 2019) to record the .webtest file. Community and Professional editions do not support this feature.
Mistake
Availability tests are real user monitoring (RUM).
Correct
Availability tests are synthetic monitoring – they simulate requests from Azure data centers. RUM captures actual user traffic. They are complementary but different.
Mistake
You can set up availability tests without an Application Insights resource.
Correct
Availability tests are a feature of Application Insights; you must have an Application Insights resource to create and manage them.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
URL ping test is a legacy test that only checks if the endpoint returns an HTTP status code within a timeout. It does not support content matching, SSL validation, or advanced options. Standard test is the modern replacement that allows you to specify success criteria based on status code range, response time, and content match. It also supports SSL certificate validation, follow redirects, and parsing dependent requests. For the AZ-204 exam, remember that Standard test is the recommended choice.
First, record the user flow using Visual Studio Enterprise (2017 or 2019) by creating a Web Performance Test project. Export the recorded test as a `.webtest` file. Then, in the Azure portal, go to your Application Insights resource, select Availability, click 'Create test', choose 'Multi-step web test', and upload the `.webtest` file. Configure frequency, locations, and alerts. Note that only Visual Studio Enterprise can record these tests.
Yes, as long as the server's endpoint is accessible from the internet. Availability tests are HTTP/HTTPS requests sent from Azure data centers. If your server is behind a firewall, you must whitelist the IP addresses of the Azure test agents (published in the Azure datacenter IP ranges). Also, the test will measure latency from the Azure region to your server, which may be higher than local users experience.
Two primary metrics: 'availabilityResults/availabilityPercentage' (percentage of successful tests) and 'availabilityResults/duration' (average response time). You can create alerts when these metrics cross a threshold (e.g., availability < 99% over 5 minutes) or when a specific number of failures occur. Alerts can be configured in the Azure portal under the Alerts blade of your Application Insights resource.
The default test frequency is every 5 minutes. You can configure it to run every 5, 10, 15, 30 minutes, or 1 hour. The minimum interval is 5 minutes. Note that the test runs independently from each selected location, so if you have 3 locations at 5-minute intervals, you'll get results every 5 minutes from each location.
If you are using a Standard test with SSL certificate validation enabled, the test will fail if the certificate is expired, revoked, or has a chain issue. The error message will indicate the SSL problem. For URL ping tests, SSL issues are not checked – the test may succeed even with an invalid certificate. This is why Standard tests are recommended for production environments.
Yes, when creating a test, you can select one or multiple test locations. You can choose a single region if you only need to monitor from that location. However, for global applications or to detect regional outages, it's recommended to select at least two regions.
You've just covered Application Insights Availability Tests — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?