Availability Tests in Application Insights

Types of availability tests

Application Insights supports four categories of availability test:

• URL ping test (classic) — Sends a single HTTP GET or HEAD request to a URL and checks the response code and optional response body content. Simple to set up, no code required. Best for checking that an endpoint is reachable.
• Standard test — Like a URL ping test but with additional options: custom HTTP headers, request body for POST requests, SSL certificate validity and expiry checking, and the ability to follow redirects or treat redirects as failures.
• Custom TrackAvailability test — You write code (typically a C# Azure Function) that performs any test scenario you define — login flows, multi-step API sequences, database connectivity checks — and calls TelemetryClient.TrackAvailability() to report results.
• Multi-step web test (deprecated) — The legacy Visual Studio web test format is supported but deprecated in favor of custom TrackAvailability tests.

Setting up a standard availability test

Creating an availability test through the CLI requires the Application Insights component to exist first. The test itself is a resource under that component.

# Ensure you have an Application Insights component
az monitor app-insights component create \
  --app myapp-insights \
  --location eastus \
  --resource-group myRG \
  --application-type web

# Create a standard availability test
# (Standard tests are created via REST API or ARM; CLI uses the classic web test format)
# Below is the ARM template equivalent as a CLI deployment

az deployment group create \
  --resource-group myRG \
  --template-file availability-test.json \
  --parameters \
    appInsightsName=myapp-insights \
    testName=homepage-availability \
    testUrl=https://myapp.azurewebsites.net/health \
    locations='["us-va-ash-azr","emea-nl-ams-azr","apac-sg-sin-azr","us-ca-sjc-azr","emea-gb-db3-azr"]'

The ARM template for a standard availability test:

{
  "type": "microsoft.insights/webtests",
  "apiVersion": "2022-06-15",
  "name": "[parameters('testName')]",
  "location": "[resourceGroup().location]",
  "tags": {
    "[concat('hidden-link:', resourceId('microsoft.insights/components', parameters('appInsightsName')))]": "Resource"
  },
  "kind": "standard",
  "properties": {
    "Name": "[parameters('testName')]",
    "Enabled": true,
    "Frequency": 300,
    "Timeout": 30,
    "Kind": "standard",
    "RetryEnabled": true,
    "Locations": [
      { "Id": "us-va-ash-azr" },
      { "Id": "emea-nl-ams-azr" },
      { "Id": "apac-sg-sin-azr" },
      { "Id": "us-ca-sjc-azr" },
      { "Id": "emea-gb-db3-azr" }
    ],
    "Request": {
      "RequestUrl": "[parameters('testUrl')]",
      "HttpVerb": "GET",
      "FollowRedirects": true,
      "ParseDependentRequests": false
    },
    "ValidationRules": {
      "ExpectedHttpStatusCode": 200,
      "IgnoreHttpStatusCode": false,
      "SSLCheck": true,
      "SSLCertRemainingLifetimeCheck": 14,
      "ContentValidation": {
        "ContentMatch": "healthy",
        "IgnoreCase": true,
        "PassIfTextFound": true
      }
    }
  }
}

Designing a testable health endpoint

Your availability test is only as useful as the endpoint it tests. A health endpoint that simply returns 200 regardless of application state provides false comfort. A well-designed health endpoint checks that critical dependencies are functioning:

# Example health endpoint response structure (JSON)
# Your /health route should check and report on critical dependencies

# A healthy response:
# HTTP 200
# {
#   "status": "healthy",
#   "checks": {
#     "database": { "status": "healthy", "latencyMs": 12 },
#     "cache": { "status": "healthy", "latencyMs": 2 },
#     "externalApi": { "status": "healthy", "latencyMs": 45 }
#   },
#   "version": "2.4.1",
#   "timestamp": "2026-03-19T14:23:01Z"
# }

# A degraded response:
# HTTP 200 (degraded but serving traffic)
# {
#   "status": "degraded",
#   "checks": {
#     "database": { "status": "healthy", "latencyMs": 14 },
#     "cache": { "status": "unhealthy", "error": "connection refused" },
#     "externalApi": { "status": "healthy", "latencyMs": 51 }
#   }
# }

# An unhealthy response:
# HTTP 503
# {
#   "status": "unhealthy",
#   "checks": {
#     "database": { "status": "unhealthy", "error": "timeout after 5000ms" }
#   }
# }

Custom availability tests with Azure Functions

For complex scenarios — multi-step login flows, OAuth token acquisition, API chains — a standard ping test is not sufficient. Custom TrackAvailability tests use an Azure Function to run arbitrary test logic on a schedule.

# The Azure Function runs on a timer trigger and calls TrackAvailability
# to report results. This example tests a two-step flow:
# 1. Authenticate to get a token
# 2. Call a protected API endpoint

# Function code (C# pseudocode pattern):
# var availability = new AvailabilityTelemetry {
#     Name = "Login and Fetch Orders",
#     RunLocation = "Custom",
#     Success = false
# };
# var stopwatch = Stopwatch.StartNew();
# try {
#     var token = await AuthenticateAsync(testUser, testPassword);
#     var orders = await GetOrdersAsync(token);
#     availability.Success = orders.Count >= 0;  // Any valid response
#     availability.Message = $"Retrieved {orders.Count} orders";
# } catch (Exception ex) {
#     availability.Message = ex.Message;
#     throw;
# } finally {
#     stopwatch.Stop();
#     availability.Duration = stopwatch.Elapsed;
#     telemetryClient.TrackAvailability(availability);
# }

Analyzing availability results with KQL

Availability test results are stored in the availabilityResults table in Log Analytics. This lets you query historical availability data, identify which locations are failing, and calculate uptime percentages.

// Calculate overall availability percentage per test in the last 7 days
availabilityResults
| where TimeGenerated > ago(7d)
| summarize
    Total = count(),
    Successes = countif(success == 1),
    Failures = countif(success == 0)
    by name
| extend AvailabilityPercent = round(100.0 * Successes / Total, 3)
| order by AvailabilityPercent asc

// Failures by location in the last 24 hours
availabilityResults
| where TimeGenerated > ago(24h)
| where success == 0
| summarize FailureCount = count() by location, name, message
| order by FailureCount desc

// Response time trend by test location
availabilityResults
| where TimeGenerated > ago(7d)
| where success == 1
| summarize
    P50 = percentile(duration, 50),
    P95 = percentile(duration, 95)
    by bin(TimeGenerated, 1h), location, name
| render timechart

Configuring availability alerts

An alert that fires on a single test failure from a single location will generate false positives from transient network issues. The recommended approach is to alert when multiple locations fail simultaneously — this is a strong signal that the endpoint itself is down rather than a single Azure test agent having a network hiccup.

# Create an availability alert using the portal or ARM template
# Alert when 3 or more locations fail at least 1 time in 5 minutes
az monitor metrics alert create \
  --name "AvailabilityFailure" \
  --resource-group myRG \
  --scopes /subscriptions/<sub-id>/resourceGroups/myRG/providers/microsoft.insights/components/myapp-insights \
  --condition "count availabilityResults/availabilityPercentage < 75" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 1 \
  --action /subscriptions/<sub-id>/resourceGroups/myRG/providers/microsoft.insights/actionGroups/OnCallTeam \
  --description "Availability below 75% across test locations"

SSL certificate expiry monitoring

Standard availability tests can check SSL certificate validity and alert when a certificate is within a configurable number of days of expiry. Configure this to 14 days minimum — certificate renewal and propagation can take time, and an expired certificate causes immediate, user-facing failures.

Pair SSL expiry checks with an activity log alert on Azure Key Vault certificate operations if your certificates are managed in Key Vault. This gives you both proactive expiry warnings and an audit trail of certificate renewals.