Microsoft has confirmed that the free URL ping tests inside Azure Application Insights will be permanently retired on September 30, 2026. After that date, every existing ping test will be removed from customer resources—no grace period, no automatic conversion. If your team relies on these lightweight checks to validate that a public endpoint is up, the clock is already ticking.

What Actually Changed

URL ping tests have been a fixture of Application Insights since its earliest days. They let you specify a URL, a few test locations, and a frequency—and that was it. No cost, no code changes, just a simple up/down signal.

Standard web tests, which have been available for years in parallel, are now the only forward path. They expand the basic GET check significantly:

  • HTTP verbs beyond GET: HEAD and POST requests, including custom request bodies and headers.
  • TLS/SSL certificate validation: proactive checks on certificate expiry and chain trust.
  • Dependent request parsing: the test can load and validate images, scripts, and stylesheets referenced by the page.
  • Retry logic: an optional three-retry policy before a failure is reported.
  • More test locations: up to 16 Azure regions, with Microsoft recommending at least five to distinguish application failures from network blips.

Crucially, Standard tests are not free. Billing is per test execution—the number of runs, multiplied by the number of locations you select. A five-minute test from five locations generates 43,200 executions per month. The exact cost depends on your agreement, region, and current Azure Monitor pricing; Microsoft warns users to consult the live pricing page before starting a migration.

Microsoft’s documentation also notes that classic URL ping tests can be discovered in bulk using Azure Resource Graph Explorer with a simple Kusto query. For those who prefer the portal, the Availability page inside each Application Insights resource still lists them under “web tests” or “availability.”

Two secondary deadlines deserve attention:

  • China East and China North test locations retire on July 1, 2026, as part of a broader Azure region retirement. If your ping tests use these locations, you must move to China East 2 or China North 2 even before the September cut-off.
  • Legacy TLS configurations are blocked from Application Insights on May 1, 2025. This includes specific cipher suites and elliptical curves; check your endpoint’s TLS stack if you’re still on very old configurations.

What It Means for You

For Azure administrators and SREs, this is a forced migration that carries both operational and financial consequences. A free monitoring signal that many teams set up years ago—and then forgot about—will become a monthly line item. The risk isn’t just a billing surprise; it’s losing visibility. If nobody migrates a critical test before September 2026, the endpoint goes dark from a monitoring perspective. The first you hear about an outage might be from a customer.

For developers and DevOps teams, the change may be an opportunity. Standard tests let you design more meaningful checks than a simple 200 OK from a home page. You can craft a lightweight health endpoint that exercises a database connection, verify that a certificate will expire soon, or POST a small payload to confirm an API contract. That can improve the signal-to-noise ratio compared with a ping that only proves the web server is running.

For FinOps or cost-conscious stakeholders, the transition introduces a new recurring charge into the Azure bill. Estimating that cost requires concrete decisions: how many locations you need, how frequently you run the test, and whether every public endpoint truly deserves its own check. The good news is that consolidation is possible—fewer, more valuable checks can replace a sprawl of duplicate or low-value pings.

Private endpoints are a notable exception. Standard tests require a publicly accessible HTTP or HTTPS endpoint. If you’ve been using a URL ping test to monitor an internal, VNet-only service, you cannot simply convert it. You’ll need an internal synthetic monitoring design: a scheduled runner inside the network, an application-hosted health probe, or something similar. Don’t expose a private service to the internet just to keep a test alive.

How We Got Here

URL ping tests debuted when Application Insights was still chasing the market for simple, no-fuss availability monitoring. They were free, easy to create, and good enough for basic checks. Over time, Microsoft introduced Standard tests (with richer features) but kept the pings around—perhaps too long.

The retirement aligns with a broader Azure philosophy: simplify the monitoring toolkit and gradually nudge users toward capability that better aligns with reliability engineering practices. It’s also part of a pattern. The Azure Monitor Agent retirement for DirectToStore on July 31, 2026, and the deprecation of older Azure regions and TLS versions, all point to a platform that’s cleaning house ahead of even larger-scale changes.

Microsoft wants customers to think about detection requirements, not just whether a URL returns a 200. The retirement notice on the Learn page doesn’t mince words: “On September 30, 2026, URL ping tests in Application Insights will be retired. Existing URL ping tests are removed from your resources.” That’s a hard stop.

What to Do Now

1. Take an Inventory of Everything

Use Azure Resource Graph Explorer with this query:

resources
| where subscriptionId == "<subscriptionId>"
| where ['type'] == "microsoft.insights/webtests"
| extend testKind = tostring(properties.Kind)
| where testKind == "ping"

Or, in the Azure portal, open each Application Insights resource, navigate to Availability under Investigate, and manually record each test’s URL, frequency, locations, and associated alert rules. Many legacy tests outlive the projects that created them; don’t assume each one is still needed.

2. Classify Every Endpoint

Work with service owners to decide what stays and what goes. A simple decision matrix:

  • Public, business‑critical endpoint → migrate to a Standard test with an appropriate detection design.
  • Public, low‑value or duplicate → consolidate, reduce frequency, or retire.
  • Private endpoint → design an internal monitoring alternative; do not expose it publicly just for a Standard test.

For each migrated test, document: owner, detection‑delay target, number of locations, cadence, and approved monthly cost. A test with no owner shouldn’t automatically become a recurring bill.

3. Estimate the New Cost

Monthly executions = number of test locations × (minutes per month ÷ frequency in minutes).
Example: 5 locations × (43,200 minutes ÷ 5-minute interval) = 43,200 executions.

Retrieve the current per‑execution rate from the Azure Monitor pricing page. Do not use a stale screenshot. Multiply the rate by your execution volume, add any separate alerting charges, and assign the forecast to a budget holder.

4. Migrate with a Controlled Runbook

For each approved replacement:

  1. On the Application Insights resource’s Availability page, select Add Standard test.
  2. Enter the public URL, HTTP verb, custom headers (if needed), locations, frequency, and success criteria.
  3. Let both the old ping test and new Standard test run in parallel for a validation period.
  4. Verify that alert rules, dashboards, and automation reference the new test. (Standard tests don’t carry over legacy alert rules automatically.)
  5. Confirm the post‑migration cost against the approved budget.
  6. Disable the legacy ping test and observe for your organization’s review period before deleting it.

If you have many tests and prefer automation, Microsoft provides a PowerShell migration script that clones a URL ping test into a new Standard test in the same resource group. It preserves frequency, locations, and timeout, but does not configure alerts—manual intervention is required.

5. Handle Private Endpoints Separately

For services only reachable via VNet or Private Link, options include:

  • A scheduled Azure Function or container job that runs inside the network and writes a custom availability result.
  • The TrackAvailability() API to post synthetic test results into Application Insights.
  • A health probe built directly into the application, monitored via log alerts.

Plan this work early; internal monitoring often requires more coordination than a public web test.

6. Review Your TLS Stack

If your endpoints still use older TLS 1.2 cipher suites (like RSA‑based AES‑CBC) or the curve25519 elliptical curve, Application Insights will block connections starting May 1, 2025. Update your endpoint’s TLS configuration immediately if you haven’t already.

Outlook

Twenty months might seem like a long timeline, but monitoring migrations have a habit of becoming emergencies when postponed. The smart approach is to treat the first half of 2025 as your audit window: find every test, assign owners, decide what’s truly needed, and model costs. By mid‑2026, you should be running parallel Standard tests and decommissioning the old pings ahead of the hard September 30 removal.

Expect Microsoft to increase the cadence of similar retirements. The push to standardize on more capable—and billable—telemetry signals is unlikely to slow. Teams that build a practice of regular monitoring hygiene will find the next deprecation far less painful.