Sysadmin Central

If your Azure monitoring strategy still relies on the old Single URL Ping Tests, you’re running out of runway. Microsoft has announced that Classic Ping Web Tests will be retired on 30 September 2026, and environments that haven’t migrated to Standard Web Tests by that date may face not only functional failures but also unexpected cost increases across your estates when you try to resolve the issue.

In this post we’ll cover:

• What’s being retired (and why)
• Why this matters
• How to estimate the cost impact
• How to migrate with minimal disruption

What’s Happening?

Azure Application Insights currently supports Classic Ping Tests, simple heartbeat-style probes that periodically ping a target endpoint and report its health. They’ve been useful for quick synthetic availability checks, but they’re limited compared to modern standards.

Microsoft’s official documentation confirms that Classic Ping Tests are being phased out in favor of Standard Web Tests. Standard Web Tests offer:

• Full HTTP/S request validation (not just ICMP-style pings)
• Customizable multi-step workflows
• Multi-region execution
• Better integration with alerts and SLO reporting

That’s great but it’s also a significant price differential compared to the legacy tests when you consider that Single URL Ping Tests are free and we’re looking at £0.00047 per scheduled test execution for Standard tests.

Why This Matters

On the surface, replacing “ping” with “HTTP GET” tests sounds harmless, but the economics are non-trivial.

Classic Ping Tests

• Very cheap (almost negligible cost)
• Limited in scope

Standard Web Tests

• Much richer feature set
• Billed per execution
• Can be significantly more expensive at scale

If you have hundreds or thousands of tests running every few minutes across multiple subscriptions, you’re going to see that cost add up quickly, case in point, I’m currently reviewing a client tenant where the costs are potentially going from about £23/month to an estimated £1916.84/month

Estimating the Cost Impact

Here’s a Resource Graph query you can run to estimate the yearly cost impact of migrating your existing Ping Tests to Standard Web Tests in East US (adjust the 0.00038 value if your dominant region uses a different rate). This breaks out all costs based on Subscription and then Location that is selected for each test.

resources
| where type == "microsoft.insights/webtests"
| extend testKind = tostring(properties.Kind),
         frequency = toint(properties.Frequency),
         locations = properties.Locations
| where testKind == "ping"
| mv-expand locations
| extend region = tostring(locations.Id)
| summarize
    totalTests = sum(2678400 / frequency),
    estCost = round(sum(2678400 / frequency) * 0.00038, 2)
  by subscriptionId, region
| order by estCost desc

What this does:

• Filters for Application Insights webtests of type ping
• Converts the ping interval into estimated monthly executions (2,678,400 = seconds in 31 days)
• Estimates cost by multiplying executions with the East US Standard Web Test rate (£0.00038 per execution)

Example Interpretation

If a subscription has:

• 1 test per second which isn’t unreasonable for larger organisations
• That’s approximately 2,678,400 executions in a month
• Estimated cost = 2,678,400 × £0.00038 = £1017.79/month
• If you’ve selected 4 locations for each test then multiply that by 4 = £4071.16/month

Scale that out across teams and subscriptions and suddenly you’re talking real budget impact.

How to Migrate with Minimal Disruption

The steps below outline a PowerShell method to automatically create a Standard Test with the same logic as an existing URL Ping Test. This is taken directly from Application Insights availability tests – Azure Monitor | Microsoft Learn

This would be relatively simple to update to retrieve a list of all URL Ping Tests, looping through them to recreate as Standard Web Tests, however, you would be much better evaluating if you need each test, whether you could reduce the frequency or make other optimisations rather than eating the cost increase.

$resourceGroup = "pingTestResourceGroup";
$appInsightsComponent = "componentName";
$pingTestName = "pingTestName";
$newStandardTestName = "newStandardTestName";

$componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
$pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
$pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
$pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;

$dynamicParameters = @{};

if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
$dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
}

if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
-and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
-and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
$dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
$dynamicParameters["ContentPassIfTextFound"] = $true;
}

New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
-Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
-RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
-Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
-RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString) -RuleSslCheck:$false;

The new standard test doesn’t have alert rules by default, so it doesn’t create noisy alerts. No changes are made to your URL ping test so you can continue to rely on it for alerts.