Site Reliability

Add health checks and autoscale to App Service

Two settings that turn a single-instance App Service into a self-healing one: a health check path so the load balancer reroutes traffic away from unhealthy instances, and an autoscale rule so the plan adds capacity under CPU and memory pressure instead of falling over.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Health checks and autoscale: the basics

Why a production App Service running on one instance is one bad request away from an outage

A web app on Azure App Service runs on one or more instances behind a load balancer. By default a new plan runs a single instance, and that single instance is a single point of failure: if the app on it hangs, leaks memory or wedges on a bad deployment, every request goes to the one place that cannot answer them. Azure Advisor surfaces two reliability recommendations that close this gap. The first, 'Enable Health check for App Service', asks you to give App Service a URL path it can ping so it can tell a healthy instance from a sick one. The second is the scale-out guidance that pairs with it: run at least two instances and let an autoscale rule add more when the plan comes under CPU or memory pressure.

Health check works by pinging the path you configure on every instance once a minute. If an instance fails to return a status code between 200 and 299 for the configured number of consecutive pings, App Service marks it unhealthy and the load balancer stops sending it traffic. If it stays unhealthy, App Service replaces it. The default failure threshold is 10 consecutive pings, tunable down to 2 through the WEBSITE_HEALTHCHECK_MAXPINGFAILURES app setting. The catch Advisor calls out explicitly: this only helps if you have somewhere to reroute to. On Free and Shared plans, which cannot scale out, an unhealthy instance is never replaced, so the recommendation is to run Basic tier or higher with two or more instances.

Autoscale is the other half. An autoscale setting on the App Service plan watches a metric, usually CpuPercentage or MemoryPercentage, and adds an instance when the metric crosses a threshold for a sustained window, then removes one when load falls away. The pairing is what makes the app resilient: health check reroutes around the instance that is already broken, and autoscale adds the headroom so a traffic spike never drives every instance into the ground at once. Neither is on by default, and most apps that fall over in production were missing one or both.

In this lesson you will learn how App Service decides an instance is unhealthy and reroutes around it, how autoscale adds capacity under load, and how to turn on both for the apps that warrant them without overspending on the ones that do not. The lesson is grounded in two Azure Advisor reliability recommendations: 'Enable Health check for App Service' and the scale-out guidance that goes with it.

Fun fact

The minute that the load balancer waits

Health check does not yank an instance out the moment one ping fails. It pings every instance once a minute, and an instance has to fail the check for the configured number of consecutive pings before it is pulled from rotation. The default is 10 consecutive failures, which means a flapping instance can keep taking traffic for the better part of ten minutes before the platform gives up on it. That default is deliberately conservative, to avoid evicting an instance over a transient blip, but for a busy production app it is often far too slow. Dropping WEBSITE_HEALTHCHECK_MAXPINGFAILURES to 2 tightens that to roughly two minutes, which is usually the right trade for a customer-facing app: fast enough to matter, slow enough not to evict on a single hiccup.

Finding the production apps with no safety net

Priya runs the platform team at a growing online retailer. Azure Advisor has started flagging 'Enable Health check for App Service' against several web apps, and a recent Saturday outage, one wedged instance that nobody noticed until customers complained, has made the recommendation suddenly concrete.

Rather than enable health check blindly everywhere, Priya starts by listing which apps actually have a health check path set and how many instances each plan runs, so the single-instance production apps, the ones with no safety net at all, can be separated from the ones that are already fine.

List each web app, whether it has a health check path configured, and how many instances its plan runs. An app with no path and one instance is the highest-risk shape.

$ az webapp list --query "[].{name:name, plan:appServicePlanId, health:siteConfig.healthCheckPath}" -o table

Name Plan Health

---------------- ------------ --------

shop-checkout asp-prod

shop-catalogue asp-prod /healthz

# shop-checkout has no health check path. Pair it with the plan's instance count next.

A revenue-bearing app such as shop-checkout with no health check path is the highest-value target. Confirm its plan runs at least two instances before, or as part of, turning health check on.

How App Service decides an instance is unhealthy and how autoscale respondsdeep dive

Health check is driven by one property on the app, siteConfig.healthCheckPath, and one app setting that tunes it. When healthCheckPath is set, App Service pings that path on every instance once a minute and expects a 2xx status code. The path must be reachable without authentication, because the pinger is anonymous, and it should do real work, checking the database connection and critical dependencies, rather than just returning 200 from a static route, otherwise it reports an instance as healthy while the app behind it is broken. An instance that fails for WEBSITE_HEALTHCHECK_MAXPINGFAILURES consecutive pings, default 10 and tunable between 2 and 10, is removed from the load balancer; if it stays unhealthy it is replaced.

The behaviour that catches people out is the dependency on scale-out. Removing an instance from the load balancer only helps if other instances are there to take the traffic. On a single instance there is nowhere to reroute to, so pulling it from rotation would mean serving nothing, and on Free and Shared plans, which cannot scale out at all, an unhealthy instance is never replaced. This is precisely why Advisor pairs the health check recommendation with scale-out guidance: the feature is only as good as the spare capacity behind it.

Autoscale lives on the App Service plan, not the app, as a Microsoft.Insights autoscale setting. It defines a profile with a minimum, maximum and default instance count, and rules that fire when a metric such as CpuPercentage or MemoryPercentage stays over a threshold for a time window. A scale-out rule adds instances; a scale-in rule removes them once load falls. A cooldown between actions stops the plan oscillating. The strongest production posture combines all three: a health check path that does real work, a failure threshold tuned to your tolerance, and an autoscale rule with a floor of at least two instances so there is always somewhere healthy to send traffic.

What is the impact of running without health checks and autoscale?

The direct impact is availability. A single-instance app with no health check has no mechanism to survive its own failure: when the instance hangs, leaks memory or wedges on a bad deploy, every request hits the one place that cannot answer, and the app is down until a human notices and restarts it. Mean time to recovery becomes however long it takes someone to be paged, diagnose and act, which on a quiet night can be the better part of an hour. With health check and a second instance, the platform reroutes around the sick instance in about a minute and replaces it, and the user-visible outage often never happens.

The second-order impact is the traffic spike that has nowhere to go. An app pinned to a fixed instance count meets a surge, a campaign, a busy Saturday, a viral moment, by driving the instances it has into saturation, where latency climbs and requests start timing out, which is its own outage. Autoscale turns that spike into a few extra instances for a few hours rather than a self-inflicted incident, and gives the capacity back when the spike passes so you are not paying for peak headroom all year.

On the reliability side, both settings are exactly what a resilience review or an Advisor reliability score will look for on a production app. A health check path and an autoscale rule with a floor of two instances are the cheapest, most legible evidence that a customer-facing app can survive a single instance failing or a normal traffic surge without becoming an incident.

How do you make an App Service self-healing safely?

Work the two settings together, in order. The order matters: give the load balancer somewhere to reroute to before you turn health check loose, so enabling it never leaves a single instance serving nothing.

1. Scale out to at least two instances first

Health check only helps if there is a healthy instance to reroute to, so move the plan to Basic tier or higher and run a minimum of two instances. On Free or Shared plans an unhealthy instance is never replaced, so a single-instance app cannot benefit from health check at all. This is the step that carries the recurring cost, so do it on the apps that warrant it.

2. Add a health check path that does real work

Set siteConfig.healthCheckPath to a dedicated route such as /healthz that actually exercises the app's critical dependencies, the database, downstream services, rather than returning a static 200. The path must allow anonymous access so the platform pinger can reach it. A shallow health check that always passes is worse than none, because it hides a broken app behind a green light.

3. Tune the failure threshold to your tolerance

The default WEBSITE_HEALTHCHECK_MAXPINGFAILURES of 10 means an instance keeps taking traffic for nearly ten minutes before it is pulled. For a customer-facing app, drop it to 2 so a wedged instance is evicted in roughly two minutes, fast enough to matter without evicting on a single transient blip.

4. Add an autoscale rule with a floor of two

Put an autoscale setting on the plan with a minimum of two instances, a sensible maximum, and a scale-out rule on CpuPercentage or MemoryPercentage with a scale-in rule and a cooldown so it does not oscillate. This keeps the safety net in place at quiet times and adds capacity for spikes, giving it back when load falls so you are not paying for peak headroom all year.

# 1. Scale the plan to Basic+ and run at least two instances first,
#    so health check has somewhere to reroute to.
az appservice plan update \
  --name asp-prod --resource-group rg-web \
  --sku B2 --number-of-workers 2

# 2. Set a health check path that exercises real dependencies,
#    and tune the failure threshold to ~2 minutes.
az webapp config set \
  --name shop-checkout --resource-group rg-web \
  --generic-configurations '{"healthCheckPath": "/healthz"}'

az webapp config appsettings set \
  --name shop-checkout --resource-group rg-web \
  --settings WEBSITE_HEALTHCHECK_MAXPINGFAILURES=2

# 3. Add an autoscale rule on the plan with a floor of two instances.
ASP_ID=$(az appservice plan show \
  --name asp-prod --resource-group rg-web --query id -o tsv)

az monitor autoscale create \
  --resource-group rg-web --name shop-autoscale \
  --resource "$ASP_ID" \
  --min-count 2 --max-count 10 --count 2

az monitor autoscale rule create \
  --resource-group rg-web --autoscale-name shop-autoscale \
  --condition "CpuPercentage > 70 avg 10m" --scale out 1 --cooldown 5

az monitor autoscale rule create \
  --resource-group rg-web --autoscale-name shop-autoscale \
  --condition "CpuPercentage < 30 avg 10m" --scale in 1 --cooldown 10

Quick quiz

Question 1 of 5

Azure Advisor recommends 'Enable Health check for App Service' on a production app running a single instance on a Basic plan. What is the correct way to act on it?

Keep learning

Go deeper on how App Service health check and Azure Monitor autoscale work and how to configure them.

You can now turn a single-instance App Service into a self-healing one: scale out to at least two instances so there is somewhere to reroute to, set a health check path that exercises the app's real dependencies, tune the failure threshold to your tolerance, and add an autoscale rule with a floor of two so the app grows under load instead of buckling. Health check reroutes around the instance that is already broken; autoscale makes sure a spike never breaks them all at once.

Back to the library

Health checks and autoscale: the cost-of-downtime view

A near-free setting plus a small, bounded capacity cost, set against the documented cost of an outage

The cost question here is the cleanest in cloud reliability work, because the two halves sit on opposite sides of the ledger. Enabling health check costs nothing: it is a path on the app you already run, pinged by a platform feature you already pay for. The only real spend is the scale-out it depends on, running at least two instances instead of one so there is somewhere to reroute traffic and somewhere for autoscale to grow into. That roughly doubles the baseline plan cost at the floor, and adds the per-instance cost of each instance autoscale spins up under load, which then drops away again when the load does.

Frame that spend against the thing it buys down: the cost of an outage. A single-instance production app that wedges is down until someone notices and restarts it, and the cost of that downtime, lost orders, idle staff, support load, refunds and reputational hit, is almost always far larger than the price of a second instance running all year. The arithmetic is the same one any availability decision turns on: the standing cost of resilience versus the expected cost of the outages it prevents.

The discipline finance brings is to put a number on both sides for the apps that matter. Not every app needs two instances and an autoscale rule; an internal tool that can be down for an hour does not. A revenue-bearing or customer-facing app almost certainly does, and for those the second instance is cheap insurance against an outage that costs orders of magnitude more.

This lesson is for the finance partner who sees a reliability recommendation against a production app and wants to know what it costs to act and what it costs not to. It covers why health check itself is free, why the scale-out it depends on is a small bounded recurring cost, and how to weigh that standing cost against the expected cost of the outages it prevents on the apps that earn revenue.

Fun fact

The minute that the load balancer waits

How a finance partner frames the resilience decision

Priya is the finance partner to the platform team. The Advisor recommendations land alongside a request to move four production apps to two instances each and add autoscale, and the instinct is not to wave the spend through, nor to reflexively block it, but to ask what each app is worth. Health check itself is free, so the only real cost is the scale-out it depends on: a second baseline instance per plan running all year, plus whatever autoscale adds during peaks and gives back afterwards. For four plans that is a predictable, bounded line, roughly the cost of doubling four baseline instances.

Priya asks the team to map each app to what an hour of it being down actually costs. The checkout app processes orders, so an hour down on a busy Saturday is measured in lost transactions and is plainly worth a second instance many times over. The catalogue app can serve stale cached pages and degrades gracefully, so its case is weaker. An internal admin tool on the same list can be down for an hour with nobody but staff affected, and does not justify the spend at all. The finance pack reads: 'Two of the four apps are clear-cut, the second instance is a fraction of one outage; one is marginal and we will run it leaner; one we will leave on a single instance and accept the risk. The recommendation is right, but it is not a flat tax across the estate.'

Why the second instance belongs on the risk register, not just the bill

The cost model here is a standing premium against an unbounded tail. The premium is visible and small: a second baseline instance running all year, plus the autoscale instances that come and go with load. The tail it buys down is the cost of an outage, which on a revenue-bearing app is dominated by lost transactions, refunds, support load and reputational damage, and which is both larger and far harder to predict than the premium. That is the shape of an insurance decision, and it should be priced like one.

The discipline is to size the premium against the exposure per app rather than buying it uniformly. For a checkout or booking app, an hour of downtime dwarfs a year of a second instance, so the case is overwhelming. For an app that degrades gracefully or an internal tool, the exposure is small and the premium may not be worth paying. Finance owns putting a credible cost-of-downtime number on each app so the spend lands where the outage risk actually is, rather than as a flat tax across every app Advisor flags.

What finance can do about the resilience gap

Finance cannot set an instance count, but it owns the framing that turns a flat reliability recommendation into a spend that lands where the outage risk actually is. Three levers.

1. Separate the free setting from the recurring cost

Make explicit that health check itself costs nothing: it is a path on an app you already run. The recurring cost is entirely the scale-out it depends on, a second baseline instance per plan plus the autoscale instances that come and go with load. Budget that as a clear per-plan line so nobody conflates 'turn on health check' with 'double the estate', and so the decision is visibly about which apps get the second instance, not about the free part.

2. Price each app by its cost of downtime, not uniformly

An hour of downtime on a checkout app and an hour on an internal admin tool are not the same number, but Advisor flags them identically. Ask the team to attach a credible cost-of-downtime figure to each flagged app, and fund the second instance and autoscale where that figure dwarfs the standing premium. The metric for the review is the recurring resilience spend set against the avoided expected outage cost per app, not the count of recommendations closed.

3. Treat the single-instance exceptions as named, accepted risks

Some apps genuinely do not warrant a second instance, and that is fine. The requirement is that leaving an app on one instance is a recorded, finance-visible decision, 'this app can be down for an hour, we accept the risk', rather than an oversight. The distinction between a deliberate accepted risk and an unnoticed single point of failure is exactly what makes the posture defensible when an outage does happen.

Quick quiz

Question 1 of 5

Advisor flags four production apps for health check and scale-out. As the finance partner, what is the right starting view of the cost to act?

Keep learning

Go deeper on how App Service health check and Azure Monitor autoscale work and how to configure them.

You have finished the finance view of App Service resilience. You know the cost model is asymmetric: health check is free, the scale-out it depends on is a small bounded recurring premium, and the downside it buys down is the larger and unbounded cost of an outage. Next time a reliability recommendation lands, you will price each app by its cost of downtime, fund the second instance where the outage dwarfs the premium, and put the single-instance exceptions on the record as accepted risks rather than treating the recommendation as a flat tax.

Back to the library

Health checks and autoscale: the headline

Whether a production app survives a sick instance and a traffic spike, or goes dark and waits for a human

This is a reliability question, not a security one. A production web app running on a single instance has no way to route around its own failure: when that instance gets sick, the app is down until someone is paged, finds the problem and restarts it. The two settings in this lesson change that. Health check lets the platform notice a sick instance in about a minute and route traffic away from it; autoscale lets the app grow under load instead of buckling. The end state is an app that absorbs a failure or a spike on its own rather than turning it into an incident.

The leadership question is not 'is the app up right now?' It is 'when an instance fails or traffic doubles at the worst possible moment, does the platform handle it, or does the business wait for a human?' Advisor flags the apps where the honest answer is the second one, and the fix is small and well understood.

This is a cost decision, but a modest and asymmetric one. Running a second instance and an autoscale rule has a real, recurring price, far smaller than the cost of the outages it prevents on any app that actually matters to the business. The decision is which apps are worth that insurance, and making sure the revenue-bearing ones are not the ones left on a single instance.

A short read for the leader who needs to know why a single-instance production app is a latent outage, what health check and autoscale actually change, and how to decide which apps are worth the modest recurring cost of running resiliently rather than on one instance.

Fun fact

The minute that the load balancer waits

What it looks like when an app heals itself instead of paging a human

After the Saturday the checkout app went dark, one wedged instance taking every order request into a wall while the on-call engineer slept through the first hour of it, the leadership question at the post-incident review was blunt: why did a single sick process take the whole shop down, and why did we find out from customers? The honest answer was that the app ran on one instance with no health check, so there was nowhere to reroute traffic and nothing watching the instance's health. It was up until it wasn't, and then it stayed down until a person intervened.

The team's response was to stop treating each app as a thing that is either up or down and start treating resilience as a property they switch on deliberately. They moved the revenue-bearing apps to two instances, set a health check path so the load balancer pulls a sick instance in about a minute, and added an autoscale rule so a traffic spike adds capacity instead of crushing what is there. The next time an instance wedged, the load balancer routed around it, autoscale had already added headroom for the morning peak, and the only sign anything had happened was a line in a dashboard. That shift, from an app that goes dark and waits for a human to one that absorbs the failure on its own, is the confidence signal this capability delivers, and for the apps that earn revenue it costs a fraction of the outage it prevents.

Why single-instance production apps are a board-level reliability risk

Most self-inflicted availability incidents share a root cause: a production app with no way to survive its own failure or a normal spike in demand. Health check and autoscale are the capability that removes that root cause, turning a sick instance or a busy hour from an outage into a non-event. The cost of getting it wrong, a customer-facing outage at the worst possible moment, is large, public and hard to bound; the cost of getting it right is a modest, predictable recurring spend on the apps that warrant it.

This is the asymmetric reliability trade leadership should be quickest to approve: severe downside from inaction on the apps that earn revenue, small and bounded cost to act. The only real decision is which apps are worth the premium, and the failure mode to avoid is discovering, during an outage, that a revenue-bearing app was the one left on a single instance to save the price of a second.

The leadership move on App Service resilience

The executive handle is not to approve each instance count individually; it is to require that the revenue-bearing apps run resiliently and that any app left on a single instance is a deliberate, owned decision.

1. Set the rule that revenue-bearing apps do not run on one instance

Ask for the simple invariant: any app that earns revenue or faces customers runs on at least two instances with a health check path and an autoscale rule. That is the floor that turns a sick instance or a busy hour from an incident into a non-event, and it is the one place where paying the premium is never in question.

2. Ask for the cost-of-downtime case, not just the bill

For each app the team proposes to make resilient, or to leave on a single instance, ask for the cost of an hour of downtime alongside the recurring cost of the second instance. The decision is an insurance one, and it can only be made well when both sides of the trade are on the table rather than just the line on the bill.

3. Require that single-instance apps are owned, accepted risks

A number of apps will not warrant the premium, and that is the right answer for them. The leadership requirement is that each such app is a deliberate, documented decision with an owner who has accepted that it can be down, not an accident discovered mid-outage. The goal is not zero single-instance apps; it is zero unintended single points of failure on the apps that matter.

Quick quiz

Question 1 of 5

At a review after a single-instance app caused an outage, what end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how App Service health check and Azure Monitor autoscale work and how to configure them.

Two takeaways. A single-instance production app is a latent outage with no way to survive its own failure, and the fix, two instances, a health check path and an autoscale rule, is a modest recurring cost that is a fraction of the outage it prevents on any app that earns revenue. And the defensible end state is not 'the app is up today'; it is that revenue-bearing apps run resiliently by design and any single-instance app is a deliberate, owned, accepted risk.

Back to the library

Part of the learning path Build in Azure resilience

Add health checks and autoscale to App Service

Health checks and autoscale: the basics

The minute that the load balancer waits

Finding the production apps with no safety net

How App Service decides an instance is unhealthy and how autoscale respondsdeep dive

What is the impact of running without health checks and autoscale?

How do you make an App Service self-healing safely?

1. Scale out to at least two instances first

2. Add a health check path that does real work

3. Tune the failure threshold to your tolerance

4. Add an autoscale rule with a floor of two

Quick quiz

Keep learning

Health checks and autoscale: the cost-of-downtime view

The minute that the load balancer waits

How a finance partner frames the resilience decision

Why the second instance belongs on the risk register, not just the bill

What finance can do about the resilience gap

1. Separate the free setting from the recurring cost

2. Price each app by its cost of downtime, not uniformly

3. Treat the single-instance exceptions as named, accepted risks

Quick quiz

Keep learning

Health checks and autoscale: the headline

The minute that the load balancer waits

What it looks like when an app heals itself instead of paging a human

Why single-instance production apps are a board-level reliability risk

The leadership move on App Service resilience

1. Set the rule that revenue-bearing apps do not run on one instance

2. Ask for the cost-of-downtime case, not just the bill

3. Require that single-instance apps are owned, accepted risks

Quick quiz

Keep learning

Related site reliability lessons