Application Insights URL Ping Tests Retire September 30, 2026

Microsoft will retire Application Insights URL ping tests on September 30, 2026, but administrators should not automatically convert every free ping into a paid Standard web test. The right move is to inventory the existing estate, price each endpoint by frequency and location count, migrate business-critical public checks, consolidate lower-value coverage, and redesign monitoring for private services that Standard tests cannot reach.
Microsoft’s Azure Monitor documentation warns that existing URL ping tests will be removed from resources on the retirement date. Because URL ping tests are free while Standard web tests are billed per scheduled execution, this is both a monitoring migration and a FinOps decision.

Inventory the Checks Before Recreating Them​

Begin by finding every legacy test across the subscriptions and Application Insights resources in scope. Availability checks often outlive the applications, deployment projects, and teams that created them, so ownership and continued business value cannot be inferred from the test’s existence.
Administrators who do not use Azure Resource Graph can perform the inventory directly in the Azure portal:

1. Sign in to the Azure portal and open the relevant Application Insights resource.
2. In the resource menu, select Availability under Investigate. Depending on the portal experience, the existing checks may also be identified as availability or web tests.
3. Open each legacy URL ping test and record its target URL, enabled state, frequency, test locations, and associated Application Insights resource.
4. Review the test’s results and related alerting configuration to determine whether anyone still depends on it.
5. Record the owning application, service team, escalation path, and business purpose outside Azure; the portal cannot supply missing organizational ownership.
6. Repeat the process for every Application Insights resource and subscription within the migration scope.

For a test approved for replacement, remain on the Application Insights resource’s Availability page, select Create or Add Standard test, and enter the approved public endpoint, request configuration, locations, and frequency. Save the test, allow it to execute, and verify its results before retiring the legacy check. Portal labels can change, so use Microsoft’s current Standard availability-test documentation alongside the live portal.
Treat the collected Azure settings as only one part of a local audit checklist. Add information that Azure cannot determine:

• The application and business service represented by the endpoint.
• Whether it is customer-facing, partner-facing, administrative, internal, obsolete, or duplicated.
• The accountable service owner and responder.
• The maximum acceptable detection delay.
• The alert rule, action group, ticketing path, or other response process currently associated with the test.
• Whether the endpoint is publicly reachable or requires private connectivity.
• The approved monthly monitoring cost.

This is the same governance problem seen in other Azure retirements. WindowsForum’s report on the Azure Monitor AgentDirectToStore retirement on July 31, 2026, emphasizes the need to find every affected data-collection design before the capability disappears. Discovery identifies resources; owners must still decide which designs remain necessary.

Classify Every Endpoint Before Migration​

A compact decision record prevents “migrate everything” from becoming the default:

Endpoint classification	Default decision
Public, business-critical endpoint	Create a Standard test with coverage tied to the service’s detection requirements.
Public, low-value or duplicate endpoint	Consolidate it, reduce its cadence, or retire it after confirming that no required signal is lost.
Private endpoint	Use an internal synthetic-monitoring design with legitimate network access; do not expose it solely for an external test.

Every decision should include these required fields:

Decision field	Required answer
Owner	Which team approves the design and responds to failures?
Detection-delay target	How quickly must the organization discover a real outage?
Location count	How many test locations are justified by users and failure scenarios?
Cadence	How often must each location run the test?
Approved monthly cost	What recurring amount has the service or platform owner accepted?

A test with no owner should not silently become a recurring charge simply because it can be recreated.

Price Executions, Not Test Objects​

Standard web-test cost is driven by scheduled test executions, not simply by the number of definitions. Each selected location executes at the configured frequency, so adding locations or shortening the interval increases volume.
Estimate monthly executions with:

Executions per month =
locations × (minutes per month ÷ frequency in minutes)

Before turning that volume into currency, retrieve the current regional and agreement-specific rate from the official Azure Monitor pricing page or the organization’s Azure pricing tools. Do not reuse a rate from this article or assume that one universal price applies across agreements, currencies, and regions.
A five-minute test operating from five locations generates five executions in every five-minute interval. Model the resulting volume under several designs:

• A critical customer transaction may justify several geographically distributed locations and a short interval.
• A regional application may need only locations that represent its actual users.
• A low-priority informational endpoint may tolerate a longer interval.
• Duplicate checks behind one public entry point may be consolidated.
• Development environments may need less frequent coverage if that matches the organization’s operating policy.

Include any separately applicable alerting and notification charges shown by the current Azure pricing material. Then assign the forecast cost to an owner and budget before deployment.
That discipline aligns with WindowsForum’s coverage of the April 2025 Azure Cost Management updates, which focused on financial accountability, and its July–August 2025 Cost Management report, which highlighted cost control across partner and multi-cloud operations. A formerly free monitor becoming metered is exactly the kind of change that requires allocation and approval before migration.

---

Standard Tests Earn Their Place on Critical Endpoints​

Standard tests offer capabilities that can produce a more useful availability signal when their configuration matches a defined operational requirement.
Microsoft documents support for HTTP GET, HEAD, and POST requests, including request bodies and custom headers. That can let a team verify a lightweight API operation or health contract instead of requesting only a generic home page. Microsoft also documents TLS/SSL validation, proactive certificate-expiration checks, and dependent-request parsing.
Those options should not be copied mechanically from an old test. Decide which behavior is necessary for the replacement and document it. Strong candidates for Standard tests include:

• Public entry points tied to service-level objectives.
• APIs requiring a particular method, body, or header to verify useful behavior.
• Internet-facing services where certificate expiration requires an operational response.
• Web applications where failure of required page resources is relevant.
• Shared public health endpoints that represent several related components.

Standard tests can use multiple Azure test locations. Microsoft recommends using at least five locations to help distinguish an application failure from an isolated network issue, but that is not an unconditional minimum for every endpoint. Location count must reflect user geography, required detection confidence, and approved cost.
The importance of representative external monitoring is also visible in WindowsForum’s report on the October 29, 2025 Azure Front Door outage. That incident is not evidence that every endpoint needs the same number of tests; it is a reminder that public-path failures need deliberately chosen signals and response ownership.

Consolidation Beats Blind Conversion​

The objective is not to preserve the number of legacy resources. It is to preserve the reliability signals operators use.
Start with duplicates. Separate teams may test the same hostname, or multiple tests may follow redirects to the same final endpoint. One properly owned check with correct routing can be better than several unmanaged copies.
Next, review endpoint granularity. Testing every node, path, and deployment slot externally may add little when internal metrics already cover those components. A public synthetic test should represent a meaningful user-visible boundary.
Cadence should follow urgency. If nobody would act on a low-priority failure until the next business day, testing it from several locations every few minutes provides little practical benefit. A revenue-critical endpoint, by contrast, should not receive a slower cadence merely to reduce cost without an explicit risk decision.
Teams should also distinguish availability monitoring from inventory reassurance. A test that exists only to show that an old URL still returns something is a retirement candidate, not automatically a migration candidate.

Private Endpoints Need a Different Monitoring Architecture​

Standard tests require publicly accessible HTTP or HTTPS endpoints. Private applications, internal APIs, and services reachable only through a virtual network therefore need another design.
Do not make a private service public solely so external test agents can reach it. Instead, run the check from a location with legitimate network access. Options may include an internal synthetic runner, a scheduled workload inside the network, an application-hosted health probe, or telemetry from a representative internal client.
Choose according to what must be measured. A component health signal can show that a process is alive, while a synthetic transaction may exercise DNS, routing, authentication, dependencies, and application behavior. Document any coverage lost when replacing one kind of signal with another.
WindowsForum has separately reported that Azure VM default outbound access will end in September. That is a distinct networking change and does not establish a general Azure design direction or change Standard tests’ public-access requirement. Administrators should evaluate its impact independently where monitoring runners depend on VM outbound connectivity.

---

Use a Staged Replacement Runbook​

Do not delete the old test as soon as a Standard test is created. Use a controlled runbook:

1. Open the relevant Application Insights resource and locate the legacy test under Availability.
2. Capture its Azure configuration and complete the local audit record for ownership, business purpose, response path, detection target, and cost approval.
3. Classify the endpoint as critical public, low-value or duplicate public, or private.
4. For an approved public replacement, create a Standard test from the Availability page using the reviewed design.
5. Allow both tests to run while administrators compare expected healthy and unhealthy behavior.
6. Audit alert rules, action groups, dashboards, workbooks, automation, and reports for references to the legacy resource. This is a local dependency check, not an assumption about what Microsoft’s migration process transfers.
7. Test the actual notification and incident path with the responsible team.
8. Recalculate expected executions using the deployed location count and cadence, then confirm the forecast against the approved monthly cost.
9. Disable the legacy test and observe the environment for the organization’s required review period before deleting it.
10. Record the replacement test, consolidated coverage, retirement decision, or internal monitoring design in service documentation.

Review thresholds and success conditions rather than assuming the old behavior is still appropriate. The purpose of parallel operation is to verify the organization’s monitoring contract, not merely to show that two resources exist.

The Deadline Turns Neglect Into Downtime Risk​

Microsoft says existing URL ping tests will be removed from resources on September 30, 2026. Teams that take no action risk losing availability data and operational coverage associated with overlooked tests.
The target should be a smaller, owned monitoring portfolio: every paid Standard test has a business reason and approved cost, every private endpoint has an appropriate internal design, and every discarded ping has been intentionally judged redundant or unnecessary.

Frequently Asked Questions​

When will Application Insights URL ping tests retire?​

Microsoft will retire them on September 30, 2026, and says existing URL ping tests will be removed from resources.

Should every URL ping test become a Standard test?​

No. Migrate critical public endpoints, consolidate or slow lower-value coverage, retire obsolete checks, and create internal monitoring designs for private endpoints.

How do I find tests without Resource Graph?​

Open each Application Insights resource in the Azure portal, select Availability under Investigate, and review its availability or web tests. Record each legacy test’s configuration, owner, purpose, alert dependencies, and network accessibility.

How do I estimate Standard-test cost?​

Calculate monthly executions as location count multiplied by minutes per month divided by frequency in minutes. Retrieve the current regional and agreement-specific rate from Azure Monitor pricing before converting executions into cost.

Can a Standard test monitor a private endpoint?​

Not directly. Standard tests require a publicly accessible HTTP or HTTPS endpoint. Use a synthetic runner or other monitoring mechanism with authorized access to the private network.

How many test locations should I use?​

Use enough locations to meet the documented detection and geographic-coverage requirement. Microsoft recommends at least five to help distinguish application failures from isolated network issues, but the final count should also reflect user distribution and approved monthly cost.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Application Insights availability tests - Azure Monitor | Microsoft Learn

   Set up recurring web tests to monitor availability and responsiveness of your app or website.

   learn.microsoft.com
2. Independent coverage: azure.microsoft.com
   
   https://azure.microsoft.com/en-us/pricing/details/monitor?msockid=18fd02f9a1ca619611a214c0a08160e0
3. Primary source: WindowsForum
   
   

   Azure VMs Default Outbound Access Ends in September: What It Means for Cloud Security | Windows Forum

   Cloud computing has always promised agility, productivity, and unlimited scale, but rarely do the default settings underpinning these promises curtail...

   windowsforum.com