Azure uptime monitoring: Azure availability monitoring, Azure website uptime monitoring and Application Insights availability tests
Short answer: Azure's built-in option is an Application Insights availability test. On September 30, 2026 the old URL ping tests retire and are removed from your resources, leaving standard tests, which are billed per execution and per location. At Microsoft's own recommended defaults, five minute frequency across five locations, one URL runs 43,833 executions a month and costs $21.92 at the East US list rate of $0.0005. That is one URL. The two things that number does not buy you are a check interval finer than five minutes at any single location, and a vantage point outside Azure. Both matter, and both are priced out below.
Last updated September 2026 · US dollar list prices, East US
alertping ▸ run check
live
▸ type a domain and run a real-feel check
▸ probes from 3 regions · FRA · IAD · SIN
▸ waiting…▌
queued probing▌
If ever goes down, you get:
Alert fired ▸ 2 channels · 6.2 s after first failure
AlertPing app
● DOWN : HTTP timeout confirmed from 3/3 regions (FRA, IAD, SIN). Incident opened.
sms · on-call
AlertPing: DOWN. Confirmed 3/3 regions . First fail: Frankfurt.
read this first
URL ping tests retire on September 30, 2026
This is the reason most people are reading this page in September 2026, so it goes first. Microsoft's documentation is unambiguous about what happens: on September 30, 2026, URL ping tests in Application Insights are retired and existing URL ping tests are removed from your resources. Not deprecated with a grace period. Removed. If a ping test is the only thing watching a production hostname, that hostname stops being watched on that date, and the alert rule attached to it stops having anything to evaluate.
The replacement is the standard test, and the migration is not a toggle. Three details catch teams out, all three straight from Microsoft's migration guidance. Creating a standard test does not modify or remove the URL ping test, so for a while you have both. Alert rules are not migrated automatically, so a working standard test with no alert rule pointed at it is a dashboard, not a monitor. And standard tests bill per execution the moment you enable them, where classic ping tests did not, which is why a fleet that cost nothing in August can arrive as a real line item in October.
Step one
Find every ping test you own
Microsoft publishes an Azure Resource Graph query that returns every
microsoft.insights/webtests resource whose kind
is ping, across all selected subscriptions.
Run it before you plan anything. Most teams find tests in subscriptions nobody has opened
in a year, attached to Application Insights resources whose owner has left.
Step two
Recreate, then move the alert
Microsoft's PowerShell snippet builds a standard test with the same URL, locations, frequency and timeout. The new test deliberately ships with no alert rule so it cannot page anyone while you validate it. That is sensible, and it is also the step people forget: until you repoint the alert rule at the new test, nothing calls you.
Step three
Price it before you enable it
Standard tests support things ping tests did not: TLS certificate validity, a proactive certificate lifetime check, custom request verbs, custom headers and a request body. They also cost money per execution per location. Work out the monthly figure from the table below before you enable a hundred of them at once.
One more dated item worth knowing if you run in Azure China: China East
(mc-cne-azr) and China North
(mc-cnn-azr) retired as availability test locations on
July 1, 2026 as part of the wider retirement of those regions. Tests pinned to them need moving to
China East 2 or China North 2.
the real bill
Azure availability monitoring is billed per execution, and locations multiply it
Here is the single most misread thing about Azure availability tests. The meter is Standard Web Test Execution, and an execution is one request from one location. Microsoft recommends a minimum of five test locations so you can tell a broken site apart from a broken network, and you can select up to sixteen. So the sticker people model in their heads, one test, is really five to sixteen billable streams running in parallel forever.
The list rate below comes from Microsoft's public retail prices API, not from a third party. It is $0.0005 per execution in East US, East US 2, West US 2 and West US 3, and $0.00056 in Central US, North Central US, South Central US, West US and West Central US. Every figure in the table uses the $0.0005 rate and a 43,833 minute month, which is the 30.44 day average.
| Configuration, one URL | Executions per month | Cost per month | Effective resolution at one location |
|---|---|---|---|
| 15 minute frequency, 5 locations | 14,611 | $7.31 | 15 minutes |
| 10 minute frequency, 5 locations | 21,916 | $10.96 | 10 minutes |
| 5 minute frequency, 5 locations (Microsoft's default) | 43,833 | $21.92 | 5 minutes |
| 5 minute frequency, all 16 locations | 140,266 | $70.13 | 5 minutes |
| Default config across 10 URLs | 438,330 | $219.16 | 5 minutes |
| Default config across 100 URLs (the per-resource cap) | 4,383,300 | $2,191.65 | 5 minutes |
Executions equal (43,833 / frequency in minutes) x locations x URLs. Rate: $0.0005 per Standard Web Test Execution, East US list price, Azure retail prices API, read September 2026. Application Insights allows up to 100 availability tests per resource.
The number worth writing down
In Microsoft's own recommended default, one URL costs $21.92 a month. Our Starter plan is $19 a month flat and covers 20 monitors, which works out at $0.95 per monitored URL. That is a 23 times difference per URL, and it is not a pricing trick on either side. It is the difference between a consumption meter that charges for every request from every location and a flat subscription that does not.
Ten URLs is where it stops being academic. Ten Azure standard tests at defaults are $219.16 a month. Our Team plan is $59 a month for 100 monitors at 30 second checks. Same job, ten times the check resolution, roughly a quarter of the bill.
Where Azure genuinely wins on price
Consumption billing cuts both ways and we are not going to pretend otherwise. If you have exactly one or two URLs and you are happy with a 15 minute check from five locations, Azure charges you $7.31 a month and we charge $19. Below roughly two and a half URLs at that interval, the meter is cheaper than our floor, and you should use the meter.
The other real Azure advantage is that the test result lands in the same Log Analytics workspace as your application telemetry. Correlating a failed availability test against the server side exception that caused it, in one query, is something no external tool can do for you.
If you also run workloads on Google Cloud, the shape of the meter there is different again: Cloud Monitoring gives you 1 million executions free per project but bills each checker region separately, which works out at 7.6 URLs before the invoice starts. GCP uptime monitoring has the full comparison.
the part price does not fix
A five minute check cannot measure a 99.99% target
Microsoft's documentation says that with a default frequency of five minutes and five test locations, your site is tested on average every minute. That sentence is true and it is also the most commonly misunderstood line in the whole feature. Every minute on average is an aggregate across five locations running on staggered schedules. It is not the resolution of any single location, and resolution is what determines the smallest outage you can record.
Each location tests every five minutes. A location that passed thirty seconds ago will not look again for four and a half minutes. Layer on the retry rule, which Microsoft recommends and which reports a failure only after three successive attempts fail at that location, and the alert rule guidance, which puts the threshold at three of five locations, and the smallest event this arrangement will confidently call an outage is measured in minutes, not seconds. Microsoft is candid about why the retry exists: about 80% of failures disappear on retry.
Now put that against the availability targets people actually sign. One failed check is the smallest recordable outage. If a single missed check is bigger than your entire monthly downtime allowance, the number in your SLA is not something your monitoring can prove.
| Availability target | Monthly downtime budget | One missed check at 5 minutes | Provable at 5 minutes? |
|---|---|---|---|
| 99.9% | 43 minutes 50 seconds | 11.4% of the budget | Yes, comfortably |
| 99.95% | 21 minutes 55 seconds | 22.8% of the budget | Yes, but coarsely |
| 99.99% | 4 minutes 23 seconds | 114% of the budget | No. One check exceeds the whole month |
| 99.999% | 26 seconds | 1,140% of the budget | No, not remotely |
Budgets computed against a 43,833 minute month (30.44 days). The best reading below 100% you can record is 99.98859% at a 5 minute interval, 99.99772% at 60 seconds and 99.99886% at 30 seconds.
This is the honest reason to run an external check alongside Azure rather than instead of it, and the reasoning generalizes past Azure. We worked through it for every interval in how often you should check uptime, and the arithmetic behind the percentages is in how to calculate uptime percentage.
the options
What each Azure uptime check actually does
Azure gives you several things that look like uptime monitoring and answer different questions. Mixing them up is how teams end up believing they are covered when they are not.
| Option | Question it answers | Runs from | Alerts on its own? |
|---|---|---|---|
| Application Insights standard test | Does this public URL respond, with the right status, string and certificate? | Azure test agents, up to 16 named locations | Only once you configure an action group. Without one you get portal notifications only |
| URL ping test (classic) | The same question, with fewer assertions | The same agents | Retired September 30, 2026. Do not build on it |
| Azure Monitor metric and log alerts | Is a resource emitting a metric outside its threshold? | Inside your subscription | Yes, with an action group |
| Front Door and Traffic Manager health probes | Which backend should receive traffic right now? | Azure edge, for routing decisions | No. They steer traffic, they do not page anyone |
| Azure Service Health | Is Azure itself having a problem? | Microsoft | Yes, but only for Azure platform events, never for your code |
| External uptime monitoring | Can a customer outside Azure load this right now, and can I prove it later? | Networks with no dependency on your Azure account | Yes, directly |
Inside the tenant
Azure watching Azure
Availability tests execute on Azure infrastructure, write to an Application Insights resource in your subscription, and raise alerts through Azure Monitor action groups. Every link in that chain lives in the platform you are trying to measure. When a regional event takes out the thing you are watching, it can take out the watcher and the notification path in the same stroke, and a monitor that goes quiet looks exactly like a service that is fine.
There is a second, quieter version of this problem. Configuration changes to an availability test can take up to 20 minutes to propagate to all test agents. During an incident, that is long enough to matter.
Outside the tenant
An independent second opinion
An external check shares nothing with your deployment: different network, different provider, different failure domain. It is the only record that means anything in an SLA conversation, because your own platform's telemetry is not neutral evidence, and it is the only thing still able to reach you when the tenant is the thing that broke.
It also catches the failures that never show up as an Azure metric at all: an expired certificate, a DNS record pointed at the wrong place after a migration, a WAF rule that started returning 403 to real users, a deploy that shipped a 200 response containing an error page.
constraints to plan around
Four Azure availability test limits worth knowing before you migrate
The endpoint has to be public
Standard tests need network reachability and public DNS resolution. If you run private DNS, the public nameservers still have to resolve the hostname or the test fails on DNS alone. For endpoints with no public ingress, Microsoft's guidance is to monitor an internal health signal and alert on that instead, which is a different product than uptime monitoring.
Test agents share IP addresses
Microsoft warns about this directly: the availability tests service uses shared IP
addresses, so allowing those IPs through your firewall can expose a protected endpoint to
traffic from other customers' tests. The documented fix is a custom header,
X-Customer-InstanceId, that your service
validates. Do not rely on IP filtering alone.
Content match is English only
The string assertion is an exact, case sensitive match with no wildcards, and Microsoft documents that only English characters are supported. If your homepage is in Spanish, German or Japanese, you cannot assert on a phrase from it, which removes the single most useful check for catching a page that returns 200 while rendering nothing.
100 tests per resource, and TLS 1.3 is regional
You get up to 100 availability tests per Application Insights resource, which is a real ceiling for an agency or a platform team with many client hostnames. Separately, TLS 1.3 is currently only available from the North Central US, Central US, East US, South Central US and West US test regions, so a TLS 1.3 only origin will fail from everywhere else.
pick one
Which Azure uptime monitoring setup fits you
Stay native
One or two URLs, 99.9% target, deep telemetry
If you have a couple of endpoints, a 99.9% commitment and you value correlating a failed check against the server side exception in the same Log Analytics query, standard tests are the right answer and they are cheap at that size. Migrate off ping tests, wire the action group, and move on.
Run both
Production revenue path, 99.95% or tighter
Keep standard tests for the diagnostic depth, and add an external check on the hostnames customers actually type, at an interval that can resolve your target. This is the common answer for most teams, and the two tools disagreeing is itself useful information: it usually means the problem is between the customer and your edge.
Go external first
Many hostnames, agencies, SLA reporting
Past roughly ten URLs the per execution meter stops being the cheap option, and past 100 per resource it stops being an option at all. If you monitor client sites or need a report you can hand to a customer, a flat plan is both cheaper and less work. That case is laid out on uptime monitoring for agencies.
straight answer
What AlertPing does not do for Azure
We are the external half of this, not a replacement for Azure Monitor, and it would be dishonest to imply otherwise. We do not read your Azure metrics, so we cannot tell you CPU on an App Service plan, DTU on a SQL database, queue depth on Service Bus or the exception that caused a 500. We have no agent, no Log Analytics integration and no way to correlate a failed check with your server side telemetry, which is a genuine Application Insights strength you should keep paying for. We cannot see private endpoints with no public ingress, and we do not run scripted browser journeys through a multi step checkout.
What we do is narrow on purpose: check public HTTP endpoints, APIs and ports from outside your tenant as often as every 30 seconds on the Team plan, confirm every failure from three regions before it counts as downtime, alert by SMS, email, Slack and webhook on every plan with no credit packs, and keep the record you need when someone asks you to prove a month. Pricing is flat from $19 a month, with 30 second checks from $59. We are also not the cheapest entry point in this market: UptimeRobot and a two URL Azure setup both beat us at the very bottom.
questions people ask
Azure uptime monitoring questions
Does Azure have uptime monitoring?
Yes. Application Insights availability tests are Azure's built in uptime monitoring. A standard test requests a public URL on a schedule from up to 16 locations and can assert on status code, a response string and TLS certificate validity. It bills per execution, needs an action group before it notifies anyone, and runs on Azure infrastructure rather than independently of it.
How do I monitor uptime in Azure?
Open your workspace based Application Insights resource, go to Availability, select Add Standard test, and enter the URL, frequency and test locations. Then open the alert rule the test creates and attach an action group, because without one you only get portal notifications. Microsoft recommends at least five locations with an alert threshold of three.
Are Azure URL ping tests being retired?
Yes. Microsoft retires URL ping tests on September 30, 2026 and removes existing ping tests from your resources on that date. The replacement is the standard test, which supports more assertions and is billed per execution. Creating a standard test does not remove the ping test, and alert rules do not migrate automatically, so both steps are manual.
How much do Azure availability tests cost?
Standard web test executions list at $0.0005 each in East US and $0.00056 in Central US and several other US regions. Billing is per request per location, so Microsoft's default of a five minute frequency across five locations is 43,833 executions and $21.92 a month for a single URL. Sixteen locations at the same frequency is $70.13.
What is the minimum interval for an Azure availability test?
Microsoft documents five minutes as the default test frequency at each location, and its stated best case, tested every minute on average, is the aggregate of five staggered locations rather than a one minute interval anywhere. There is no sub minute option, which is the practical limit when you need to evidence a 99.99% target.
Is Application Insights availability monitoring free?
No. Microsoft states plainly that standard tests incur charges once enabled, and the docs tell you to review Azure Monitor pricing before migrating. Classic URL ping tests were not separately metered, which is why teams migrating before the September 30, 2026 retirement often see a new line item appear rather than a like for like swap.
Can Azure monitor a website hosted outside Azure?
Yes. An availability test works against any HTTP or HTTPS endpoint reachable from the public internet, including third party services your application depends on. You still need an Application Insights resource to hold the test, and you are still billed per execution per location for it.
Do I need external monitoring if I already use Azure Monitor?
If your target is 99.9% and you have one or two endpoints, no. If you have signed 99.95% or tighter, or you need evidence a customer will accept, then yes, because a five minute interval cannot resolve those budgets and a measurement taken inside the platform is not a neutral record of that platform's availability.
How many availability tests can I create in Application Insights?
Up to 100 per Application Insights resource. At Microsoft's default configuration, 100 tests is 4,383,300 executions and $2,191.65 a month at the East US rate. Teams that need more hostnames than that have to split across resources, which also splits the reporting.
What is the difference between Azure availability monitoring and health probes?
Health probes in Front Door, Traffic Manager and Load Balancer exist to make routing decisions, so they take a backend out of rotation and tell nobody. Availability tests exist to record and alert. A site can be fully healthy from the probe's point of view, because traffic failed over correctly, while customers in one region see errors.
Watch your Azure endpoints from outside your Azure tenant
AlertPing checks your App Service, Front Door, Application Gateway and API Management endpoints as often as every 30 seconds, confirms every failure from three regions before it counts as downtime, and sends SMS, email, Slack and webhook alerts on every plan with no credit packs. Flat pricing from $19 a month.
keep reading