Site Reliability

Run App Service with at least two instances

A production App Service plan running on a single instance is one routine VM move, patch or restart away from a cold-start interruption or an outright outage. Azure Advisor flags it for a reason: two instances is the floor for surviving the loss of one.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Two instances: the basics

Why does Azure Advisor flag an App Service plan running on one instance?

An App Service plan is the pool of virtual machines your web apps run on, and the instance count is simply how many of those VMs the plan keeps running. When the count is one, every app on that plan lives on a single VM, and that VM is a single point of failure. App Service moves and upgrades the underlying VMs as part of normal platform operation: OS and runtime patching, hardware retirement, scaling events. Each of those can restart or relocate your only instance, and while the platform restarts it, requests have nowhere else to go.

Azure Advisor surfaces this as a reliability recommendation: scale a production App Service plan out to at least two instances. The reasoning is concrete rather than abstract. With two or more instances, the load balancer can keep serving traffic from the healthy instance while the platform moves or patches the other one, and the App Service Health Check feature, which only takes effect with two or more instances, can pull a misbehaving instance out of rotation without dropping your app. With one instance, there is nothing to fail over to and Health Check has nothing to compare against.

There is a second, quieter reason. If your app has a slow start, a heavy framework, a large in-memory cache, a warm-up routine, then a single-instance plan exposes that cold start to every visitor whenever the platform recycles the VM. The app is technically online while it cold-starts, but the first requests are slow or time out. Two instances let the platform recycle one at a time, so there is always a warm instance answering while the other comes back.

In this lesson you will learn why a single-instance App Service plan is a single point of failure, how the platform's routine maintenance turns that into real downtime and cold-start interruptions, and how to move your production plans to a resilient minimum of two instances with one CLI command or a one-line change in your infrastructure code. You will also see where the line sits between apps that genuinely need the second instance and the internal tools that can stay on one.

Fun fact

The Health Check that only checks when it has company

App Service Health Check, the feature that pulls a sick instance out of the load balancer so it stops serving errors, does nothing at all on a single-instance plan. The logic is deliberate: if App Service removed your only instance, your app would be entirely down, which is worse than serving from a struggling one. So Health Check only takes effect with two or more instances, and there is a further safeguard, if every instance is unhealthy, none are removed, because taking them all out of rotation would be a self-inflicted outage. The feature you turned on to improve reliability is quietly inert until you give it a second instance to work with.

Finding single-instance production plans

Priya runs the platform team at a SaaS company. Azure Advisor has raised a reliability recommendation against the App Service plan behind the customer portal, the company's main revenue front door, telling her to scale it out to at least two instances.

Rather than act on the one Advisor flag, she starts by listing every App Service plan in the subscription with its current instance count and tier, so she can see how many production plans are running on a single instance before deciding which ones to fix first.

List every App Service plan with its instance count, tier and worker count. Any production plan showing a capacity of 1 is a single point of failure.

$ az appservice plan list --query "[].{name:name, tier:sku.tier, instances:sku.capacity}" -o table

Name Tier Instances

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

portal-prod-plan PremiumV3 1

api-prod-plan PremiumV3 2

internal-tools Basic 1

# portal-prod-plan is the revenue front door on ONE instance. Fix this first.

A revenue-bearing PremiumV3 plan on a single instance is the highest-value target. The Basic internal-tools plan on one instance may be a deliberate, acceptable choice; decide per app, not per flag.

How a single instance turns routine maintenance into downtimedeep dive

The instance count lives on the App Service plan as 'sku.capacity', the number of worker VMs the plan runs. Every web app assigned to that plan runs on every one of those workers, and the platform's load balancer distributes traffic across them. With capacity set to 1, there is exactly one worker, so there is no second target for the load balancer and no instance to fail over to. App Service performs routine maintenance on these workers as a normal part of operation: it patches the OS and language runtime, retires and replaces underlying hardware, and applies platform updates, and any of these can restart or relocate your worker. On a single instance, that recycle is visible to users as a restart, and if your app is slow to start, as a cold-start delay on the first requests.

App Service Health Check changes behaviour entirely depending on instance count. With two or more instances, an instance that fails to return a 2xx response across repeated probes is removed from the load balancer so it stops serving errors, and if it stays unhealthy for an hour the platform replaces it with a fresh one. With a single instance, Health Check is effectively a no-op, because removing the only instance would take the app fully offline, the platform never does that. There is also a deliberate safeguard at the top end: if all instances are unhealthy at once, none are removed, so a bad deploy that sickens every instance does not get amplified into a full blackout by Health Check itself.

Two instances is therefore the floor for the platform's self-healing to function at all, and it is also the precondition for zone redundancy. To spread an App Service plan across availability zones, so the loss of an entire datacentre zone does not take the app down, you need a minimum of two instances on a Premium v2 or higher plan; the platform enforces that floor and bills for it. Adding the second instance is the step that takes you from 'survives nothing' to 'survives a single instance loss', and unlocks the path to 'survives a zone loss'.

What is the impact of running production on one instance?

The direct impact is avoidable downtime and slow requests. Because the platform recycles workers for patching, hardware retirement and updates on its own schedule, a single-instance production app will be interrupted by events you did not initiate and cannot fully predict. Each interruption is short, but it lands without warning, during business hours as easily as overnight, and on a revenue-bearing app each one is lost transactions and a worse customer experience. For apps with a meaningful cold start, the impact is larger: the first wave of requests after every recycle is slow or times out while the app warms up.

The second-order impact is that your reliability tooling does not work. Health Check, the feature meant to detect and eject a failing instance, is inert on one instance. There is no headroom to absorb a traffic spike or a slow instance, because there is no second instance to share load. And you are blocked from the next reliability step entirely: zone redundancy requires at least two instances, so a single-instance plan cannot survive a zone outage no matter what else you configure.

On the governance side, every reliability and operational-resilience expectation, internal SLOs, customer-facing uptime commitments, and the operational-resilience requirements that regulated sectors now face, assumes your production services can survive the loss of a single component. A production app whose architecture cannot survive its one server being restarted is a documented gap against any of those, and a single Advisor reliability recommendation left open is the clearest possible evidence of it.

How do you move production to a resilient minimum?

Work this as a quick triage rather than a blanket change. The goal is a second instance on every plan where downtime has a real cost, and a recorded, deliberate exception on the few where it does not.

1. Inventory plans by instance count and what they serve

List every App Service plan with its tier and current capacity. For each single-instance plan, note what it serves and roughly what an hour of its downtime costs. This is the source of truth, not the single Advisor flag, because Advisor highlights individual plans while the decision is best made across the estate.

2. Scale out the revenue-bearing plans to at least two

For any plan behind a customer-facing or revenue-generating app, raise the worker count to at least two. This is a single command per plan and takes effect without redeploying your app. Two is the floor; for apps with a slow cold start or heavier traffic, three is the more comfortable minimum the reliability guidance suggests.

3. Turn on Health Check and, where it matters, zone redundancy

With two or more instances, enable App Service Health Check so a sick instance is pulled from rotation automatically. For the highest-criticality apps, take the next step and make the plan zone redundant on a Premium v2 or higher tier, which spreads the instances across availability zones so the loss of an entire zone does not take the app down. Zone redundancy itself requires the minimum of two instances you have just set.

4. Bake the floor into your infrastructure code

Set the instance count in the Bicep or ARM template that defines the plan, so a future redeploy cannot quietly drop a production plan back to one instance. Encoding the minimum in the template is the difference between fixing the count today and guaranteeing it stays fixed across every future deployment.

# Scale a production App Service plan out to two instances. Takes effect
# without redeploying the app. --number-of-workers accepts 1 to 30.
az appservice plan update \
  --name portal-prod-plan \
  --resource-group portal-prod-rg \
  --number-of-workers 2

# Enable Health Check on the web app so a sick instance is ejected
# from the load balancer (only effective with two or more instances).
az webapp config set \
  --name portal-prod \
  --resource-group portal-prod-rg \
  --generic-configurations '{"healthCheckPath": "/health"}'

Quick quiz

Question 1 of 5

Azure Advisor recommends scaling a production App Service plan out to at least two instances. What is the core reason?

Keep learning

Go deeper on why two instances is the production floor for App Service, and how it connects to Health Check and zone redundancy.

You can now treat a single-instance production App Service plan for what it is: an avoidable single point of failure that the platform's own routine maintenance will eventually trip. Inventory your plans by instance count and what they serve, scale the revenue-bearing ones out to at least two, turn on Health Check so the new headroom self-heals, take the critical apps zone redundant, and bake the minimum into your infrastructure code so a redeploy cannot undo it.

Back to the library

Two instances: the cost-of-downtime view

The price of a second instance versus the price of an outage on your single one

This is one of the clearest cost-versus-risk trades in the platform, because both sides are quantifiable. The cost of resilience is the marginal price of one additional App Service instance on the same plan tier: a known, fixed, monthly number you can read straight off the pricing for your SKU. The cost of leaving the plan on a single instance is the expected cost of the outages and slow-starts that the missing instance would have absorbed, every routine patch, VM move and restart that the platform performs without asking.

Frame it as the two-instance plan being the insurance premium and the single-instance plan being self-insurance against your own revenue-bearing front door. For a low-traffic internal tool, self-insurance may genuinely be the right call, the downtime costs nothing meaningful. For a customer-facing or revenue-generating app, the premium of a second instance is almost always smaller than the expected cost of the interruptions it removes, and unlike most insurance it also removes the cold-start tax on every recycle, which is a customer-experience cost that never shows up on the bill.

The finance role here is not to approve a blanket second instance everywhere. It is to separate the apps where downtime has a real cost from the ones where it does not, price the second instance against that downtime cost per app, and make sure the revenue-bearing apps are not running one VM away from an outage to save a few pounds a month.

This lesson is for the finance partner who sees an Azure Advisor reliability recommendation to scale out an App Service plan and wants to know what it actually costs, what risk it removes, and how to decide which apps warrant the second instance. It covers how to price the second instance against the cost of an outage, and how to avoid both extremes: leaving a revenue app exposed and over-provisioning every internal tool.

Fun fact

The Health Check that only checks when it has company

How a finance partner frames the second-instance decision

Priya is the finance partner supporting the platform team. The Advisor reliability recommendation against the customer-portal plan lands on the cost-and-reliability review, and alongside it the platform list shows two more single-instance plans. The instinct is not to wave through a second instance on all three; it is to price each one against the downtime it would remove. A second PremiumV3 instance on the portal plan is a known fixed monthly figure she can read straight off the SKU pricing, and the portal is the company's revenue front door, so the relevant comparison is that fixed premium against the cost of the portal being slow or down during every routine platform patch and VM move.

She asks the team to tag each single-instance plan with what it serves and what an hour of its downtime costs. The customer portal is high revenue per hour: the second instance is trivially justified and goes in today. The production API plan is already on two, no action. The internal-tools plan on Basic serves a back-office form used by a handful of staff in working hours, where an occasional cold start costs nothing meaningful, so it stays on one as a recorded, deliberate exception. The finance pack reads: 'One second instance added to the revenue front door at a known monthly cost that is a small fraction of an hour of portal downtime; one internal tool left single-instance on purpose because its downtime is immaterial.'

Why the second instance belongs in the budget, not on the risk register as an open item

The cost model here is unusually clean. The cost of the fix is a single line: the marginal monthly price of one more instance at the plan's existing tier, fixed and known in advance. The cost of not fixing it is the expected value of the outages and slow-starts that the second instance would have absorbed, which for a revenue-bearing app is a function of revenue per hour and the frequency of platform recycles. For most customer-facing apps, even a conservative estimate of downtime cost dwarfs the price of the instance.

What makes this an easy decision to get right is that both numbers are available without a study. The instance price is on the pricing page. The downtime cost is revenue per hour times an outage duration, a number the business already understands. The finance role is to put those two numbers next to each other per app, approve the second instance wherever the downtime cost clearly exceeds the premium, and explicitly accept single-instance running only where the downtime genuinely costs nothing, recorded as a deliberate exception rather than left as an unanswered Advisor flag.

What finance can do about the single-instance gap

Finance cannot scale a plan, but it owns the framing that turns an Advisor reliability flag into a per-app decision priced against real downtime cost, rather than either an ignored warning or a blanket spend. Three levers.

1. Price the second instance against downtime cost, per app

Put two numbers side by side for each single-instance plan: the fixed marginal monthly price of a second instance at the plan's tier, and the cost of an hour of that app's downtime. Approve the second instance wherever the downtime cost clearly exceeds the premium, which for any revenue-bearing app it almost always does. This stops the recommendation being treated either as a cost to dodge or as a reason to over-provision everything.

2. Separate revenue-bearing apps from genuinely low-stakes ones

Not every single-instance plan needs fixing. A back-office tool used by a few staff in working hours, where a cold start costs nothing meaningful, can stay on one instance. The finance contribution is to make that distinction explicit and defensible, so the spend lands on the apps where downtime has a real cost and is consciously withheld where it does not.

3. Require a recorded reason for any single-instance production plan

Any production plan deliberately left on a single instance should carry a recorded, finance-visible reason: this app's downtime is immaterial, accepted on purpose. The distinction between 'we priced the second instance against the downtime and chose not to' and 'we never actioned the Advisor flag' is exactly what makes the posture defensible at the next reliability review or after any incident.

Quick quiz

Question 1 of 5

An Advisor reliability flag recommends a second instance on the customer-portal plan. As the finance partner, how should you size the decision?

Keep learning

Go deeper on why two instances is the production floor for App Service, and how it connects to Health Check and zone redundancy.

You have finished the finance view of the two-instance minimum. You know the cost model is unusually clean: the fix is a fixed monthly instance price you can read off the pricing page, and the downside of inaction is the cost of outages and cold-starts on the apps that earn revenue. Next time an Advisor reliability flag lands on a plan, you will price the second instance against that app's downtime cost, approve it where the downtime clearly costs more than the premium, and record a deliberate exception where it does not, rather than treating the flag as either a cost to dodge or a reason to over-provision everything.

Back to the library

Two instances: the headline

Whether your production front door can survive losing one server it never chose to lose

A single-instance production app is a business that depends on one machine that Microsoft will restart, move or patch on its own schedule, without warning you. When that happens, your app is briefly down or slow, and you find out from customers rather than from a change you made. Azure's own Advisor flags this as a reliability risk because it is the most common avoidable single point of failure in an App Service estate.

The leadership question is not 'is the app up right now?' It is 'when the platform inevitably recycles the server under it, does the app stay up?' On one instance the answer is no, by design. On two or more, the answer is yes for the routine events that cause most avoidable downtime, and it is a precondition for the next step up, spreading those instances across availability zones.

This is a cost decision, but a small and well-bounded one. The choice is between paying for a second instance on the apps that matter and absorbing the cost and reputational hit of outages on those same apps. For anything customer-facing or revenue-bearing, that is rarely a close call.

A short read for the leader who needs to understand why a production app on one instance is a single point of failure the platform can trip at any time, why fixing it is a small and bounded cost decision rather than a project, and what a defensible end state looks like across the estate.

Fun fact

The Health Check that only checks when it has company

What it looks like when the front door survives a server it never chose to lose

After a competitor had a public wobble during what turned out to be routine cloud maintenance, the CEO asked the obvious question at the next review: when our platform provider restarts or moves the servers under our app, does the app stay up? The honest answer for the customer portal at the time was no, because it ran on a single instance, so any platform-initiated recycle of that one VM took the portal offline or cold for as long as it took to come back.

The team's response was not a re-architecture. They added a second instance to the portal plan, confirmed the load balancer now kept serving from the healthy instance while the platform recycled the other, and turned on Health Check, which had been inert on a single instance and could now actually pull a sick instance out of rotation. They left the genuinely low-stakes internal tool on one instance as a documented choice. The next time the CEO asked the question, the answer for the revenue-bearing app had changed from 'no, we depend on one server staying up' to 'yes, the platform can take one instance and the app keeps serving, and the next step is spreading those instances across availability zones.' That shift, from depending on a single server nobody controls to surviving its loss, is the confidence signal this recommendation delivers, for a small and known monthly cost.

Why a single point of failure on the front door is a leadership issue

Almost every avoidable App Service outage traces back to the same root cause: a production app running on one instance that the platform restarted, moved or patched as routine. It is not a sophisticated failure mode, it is the absence of a spare, and the platform provider's own Advisor flags it because it is both common and cheap to fix.

The cost of fixing it is small, fixed and visible; the cost of leaving it is variable, unpredictable and lands at the worst possible moments without warning. This is the rare reliability decision where the downside of inaction is concrete customer-facing downtime and the cost of action is a known monthly figure on the apps that matter, which is exactly the trade leadership should approve quickly for anything revenue-bearing.

The leadership move on single points of failure

The executive handle is not to approve each scale-out individually; it is to require that no revenue-bearing app runs on a single instance, and that any deliberate exception is recorded with an owner.

1. Set the rule: no revenue app on one instance

Ask for a simple, checkable end state: every customer-facing or revenue-generating App Service plan runs on at least two instances, with the critical ones zone redundant. This is a small, bounded cost on a known set of apps, and it removes the most common avoidable single point of failure in the estate. Make it a standing rule rather than a one-off remediation, so new apps inherit it.

2. Ask for proof, not assurance

The proof that this is closed is not 'we are on it.' It is a list of production plans showing two or more instances, the Advisor reliability recommendations cleared, and the minimum encoded in the infrastructure templates so a future deploy cannot undo it. Ask to see the instance count baked into the code, not just set once by hand.

3. Treat single-instance production as a named, owned exception

A few low-stakes apps may stay on one instance, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner who has accepted that the app's downtime is immaterial, not an Advisor flag nobody actioned. The goal is not two instances everywhere; it is zero revenue-bearing apps left as an unintended single point of failure.

Quick quiz

Question 1 of 5

At a board review you ask whether the customer portal stays up when the platform restarts the server under it. On a single instance, what is the honest answer?

Keep learning

Go deeper on why two instances is the production floor for App Service, and how it connects to Health Check and zone redundancy.

Two takeaways. A production app on one instance is a single point of failure the platform can trip at any time, and fixing it is a small, bounded and quick-to-approve cost on the apps that matter. And the defensible end state is not 'the app is up today'; it is every revenue-bearing plan on at least two instances, the critical ones zone redundant, the minimum encoded in infrastructure code, and the few deliberate single-instance apps documented and owned.

Back to the library

Part of the learning path Build in Azure resilience

Run App Service with at least two instances

Two instances: the basics

The Health Check that only checks when it has company

Finding single-instance production plans

How a single instance turns routine maintenance into downtimedeep dive

What is the impact of running production on one instance?

How do you move production to a resilient minimum?

1. Inventory plans by instance count and what they serve

2. Scale out the revenue-bearing plans to at least two

3. Turn on Health Check and, where it matters, zone redundancy

4. Bake the floor into your infrastructure code

Quick quiz

Keep learning

Two instances: the cost-of-downtime view

The Health Check that only checks when it has company

How a finance partner frames the second-instance decision

Why the second instance belongs in the budget, not on the risk register as an open item

What finance can do about the single-instance gap

1. Price the second instance against downtime cost, per app

2. Separate revenue-bearing apps from genuinely low-stakes ones

3. Require a recorded reason for any single-instance production plan

Quick quiz

Keep learning

Two instances: the headline

The Health Check that only checks when it has company

What it looks like when the front door survives a server it never chose to lose

Why a single point of failure on the front door is a leadership issue

The leadership move on single points of failure

1. Set the rule: no revenue app on one instance

2. Ask for proof, not assurance

3. Treat single-instance production as a named, owned exception

Quick quiz

Keep learning

Related site reliability lessons