Site Reliability

Give Front Door multiple origins for failover

One reliability capability: make sure every Azure Front Door origin group has more than one origin, so that when a single backend goes down, traffic shifts to a healthy one instead of the whole site going dark.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Multiple origins for Front Door: the basics

What does a single-origin Front Door actually look like when the backend fails?

Azure Front Door is the global front end for a web application: every request from your users lands on a Front Door edge location and is forwarded to an origin, the actual backend that serves the content. An origin group is the set of origins Front Door can choose from for a given route, and Front Door health-probes each one and load-balances between them. The reliability question is simple: how many origins are in that group? If the answer is one, then Front Door has nowhere to send traffic the moment that single backend becomes unavailable, and the global front end you paid for cannot do the one thing it is best placed to do, which is route around a failure.

Azure Advisor surfaces this directly. The reliability recommendation 'Consider having at least two origins' flags any Front Door profile whose origin group has a single origin. Microsoft's own words: multiple origins support redundancy by distributing traffic across multiple instances of the application, so that if one instance is unavailable, other backend origins can still receive traffic. Advisor rates the impact as High and files it under the HighAvailability subcategory, because a single origin is a single point of failure sitting behind an otherwise highly available service.

Most single-origin setups are not a decision, they are a starting point nobody revisited. A team stands up Front Door in front of one App Service or one storage static site to get TLS, caching and a clean custom domain, ships it, and moves on. The origin group quietly stays at one. The work in this lesson is to find every Front Door origin group with a single origin, add a second origin (a paired-region backend, a standby slot, or a second instance), set priorities so one is primary and the other is the failover, and let Front Door's health probes handle the cutover automatically.

In this lesson you will learn how Azure Front Door uses origin groups, origins, priorities and health probes to route around a failed backend, why a single-origin group is a single point of failure that Advisor flags as High impact, and how to add a second origin and prove the failover works without taking the live service down. The focus throughout is downtime risk: what an outage actually costs versus what resilience costs.

Fun fact

The highly available front end with one place to go

It is a common surprise that a service explicitly designed for high availability, with a global anycast network and dozens of points of presence, can still be brought down by one backend. Front Door's edge has well over a hundred locations worldwide and almost never fails as a whole. The single point of failure is not Front Door, it is the origin group with one origin in it. Front Door will keep accepting requests from every corner of the planet and then have exactly one backend to forward them to. The resilience you are buying from the edge is only as deep as the number of healthy origins it can choose from.

Finding single-origin Front Doors across a subscription

Priya runs platform engineering at a SaaS company that put several apps behind Azure Front Door over the past two years to get managed TLS and a global edge. Azure Advisor is now showing 'Consider having at least two origins' against three of those profiles.

Before changing anything, Priya wants to see which origin groups actually have a single origin and which service sits behind each, so the customer-facing ones can be prioritised over the internal tooling.

List the origins in an origin group. A group that returns a single origin is the one Advisor is flagging.

$ az afd origin list --resource-group rg-edge --profile-name fd-shop --origin-group-name og-shop --query "[].{name:name, host:hostName, priority:priority, enabled:enabledState}" -o table

Name Host Priority Enabled

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

shop-eastus shop-eastus.azurewebsites.net 1 Enabled

# Only one origin in og-shop. A failure here has nowhere to go: full outage.

A single-origin group is the whole risk in one line. The next step is to add a second origin and set priorities so one is primary and the other is failover.

How Front Door routes around a failed origindeep dive

Front Door continuously sends health probes to every enabled origin in an origin group. The origin group's load-balancing settings define how those probes are read: a sample size and a number of successful samples required mean an origin is only marked unhealthy after it fails several consecutive probes, which avoids flapping on a single blip. When an origin is judged unhealthy, Front Door stops sending it traffic and uses the remaining healthy origins instead. With only one origin in the group, there is no remaining healthy origin, so there is nothing for the probe result to do: the failure becomes a full outage.

Failover behaviour is driven by each origin's priority, a value from 1 to 5 where a lower number means higher priority. Front Door routes to the healthy origins with the lowest priority value; if all of those become unavailable, it moves to the next priority level. So a primary origin at priority 1 and a standby at priority 2 gives you active-passive failover: all traffic goes to the primary while it is healthy, and the instant it fails its probes, Front Door shifts to the priority-2 standby with no configuration change. Setting both origins to the same priority instead gives you active-active, with weight controlling the traffic split.

The cutover is not instant to the millisecond, and that is deliberate. The detection time depends on the probe interval and the successful-sample threshold you configure: a shorter interval fails over faster but probes the backends harder. The point is that the cutover is automatic and bounded in seconds to a couple of minutes, rather than open-ended and dependent on a human noticing. Adding the second origin is what turns the health probe from a passive status light into an actual failover mechanism.

What is the impact of leaving Front Door on a single origin?

The direct impact is unmitigated downtime. A single-origin Front Door has no failover, so any event that takes the one backend offline, a bad deployment, a regional incident, a dependency failure, a resource exhaustion, takes the whole service offline with it. The global edge keeps answering and has exactly one place to forward to, and that place is down. Recovery depends entirely on a person detecting the problem and fixing or repointing the origin, which turns a seconds-long automatic cutover into a minutes-or-hours manual incident.

The second-order impact is that it concentrates risk on your single busiest moment. Backends fail most often under load and during change, which is precisely when an outage costs the most: peak traffic, a launch, a sale. A single origin means your reliability is only as good as that one backend's worst day, and you have given up the one tool, automatic global failover, that the front end was meant to provide.

On the assurance side, resilience reviews, customer due-diligence questionnaires and availability commitments increasingly ask whether internet-facing services survive the loss of a single component. 'Every customer-facing Front Door has at least two origins with automatic failover' is a clean, demonstrable answer. A single-origin profile is the opposite: a documented single point of failure sitting in front of the services you most need to keep up.

How do you add failover safely?

Work the capability as one loop rather than chasing each finding in isolation. The order matters: stand up and verify the second origin before you rely on it, so the failover path is proven and the change never risks the origin that is currently serving traffic.

1. Inventory every single-origin origin group

For each Front Door profile, list the origins in every origin group and find the ones with a single origin. Map each to the service behind it and what an hour of its downtime costs. Treat that downtime cost, not the raw finding count, as the source of truth for ordering the work.

2. Choose the second origin per service

Decide what the failover target is for each service: a standby instance in a paired Azure region, a second App Service or App Service slot, or an existing second instance you already run. A passive standby can be sized small. The only requirement is that it can serve the same content and answer the same health probe path as the primary.

3. Add the origin and set priorities for active-passive

Add the second origin to the same origin group. Set the primary to priority 1 and the standby to priority 2 so all traffic stays on the primary until it fails its probes, then shifts automatically to the standby. Give both origins the correct origin host header so the backend accepts the request.

4. Prove the failover, then bake it into deployment

Verify the cutover before trusting it: take the primary out of service in a controlled test and confirm traffic moves to the standby. Then put the two-origin pattern into the Bicep or template that provisions every new Front Door, so resilience is the default rather than something added after Advisor flags it.

# Add a second origin as the priority-2 failover target in an existing origin group.
# Front Door does not charge per origin; the cost is the standby backend itself.
az afd origin create \
  --resource-group rg-edge \
  --profile-name fd-shop \
  --origin-group-name og-shop \
  --origin-name shop-westus \
  --host-name shop-westus.azurewebsites.net \
  --origin-host-header shop-westus.azurewebsites.net \
  --priority 2 \
  --weight 1000 \
  --enabled-state Enabled \
  --https-port 443 \
  --http-port 80

# Make sure the existing primary is priority 1 so it stays the active origin.
az afd origin update \
  --resource-group rg-edge \
  --profile-name fd-shop \
  --origin-group-name og-shop \
  --origin-name shop-eastus \
  --priority 1

# Bake the two-origin pattern into the template so resilience is the default.
# Bicep: a priority-2 standby alongside the priority-1 primary in the same group.
#
# resource standby 'Microsoft.Cdn/profiles/originGroups/origins@2025-12-01' = {
#   parent: originGroup
#   name: 'shop-westus'
#   properties: {
#     hostName: 'shop-westus.azurewebsites.net'
#     originHostHeader: 'shop-westus.azurewebsites.net'
#     httpPort: 80
#     httpsPort: 443
#     priority: 2
#     weight: 1000
#     enabledState: 'Enabled'
#     enforceCertificateNameCheck: true
#   }
# }

Quick quiz

Question 1 of 5

Azure Advisor raises 'Consider having at least two origins' against a Front Door profile. What is it actually telling you?

Keep learning

Go deeper on how Azure Front Door uses origins, origin groups, priorities and health probes to deliver automatic failover.

You can now treat Front Door failover as one reliability capability rather than a scatter of findings: inventory every single-origin origin group, map each to what its downtime costs, add a standby origin at priority 2 behind a priority-1 primary, prove the cutover in a controlled test, and bake the two-origin pattern into your templates so resilience is the default. The single point of failure was never Front Door's edge, it was the origin group with one origin in it.

Back to the library

Multiple origins for Front Door: the downtime-cost view

A small, bounded resilience cost set against the open-ended cost of an outage

A single-origin Front Door is a bet that the one backend behind it never has a bad day. When that bet loses, the front end has nowhere to fail over to and the site is simply down until someone fixes the origin by hand. The cost of that downtime is rarely a line on the Azure bill, it is lost revenue per minute, support and incident-response time, breached customer commitments and the reputational hit of a public outage. That is the figure to hold in mind, because the cost of resilience is almost always small against it.

The remediation cost is bounded and predictable: a second origin to fail over to. Depending on the design that is a standby instance in a paired region, a second App Service plan, or simply pointing at an existing instance you already run. Front Door itself does not charge per origin, so adding a second origin to a group costs nothing in Front Door terms; the cost is whatever compute or storage the second backend consumes, and a passive standby can be sized small. Frame it as buying down a known downtime exposure for a known monthly figure.

Treat each flagged origin group as a risk-register line, not a checkbox. A Front Door fronting the revenue-generating application carries a very different expected downtime cost from one fronting an internal tool, yet both show up as the same single Advisor finding. Map each to the service behind it and prioritise by what an hour of its downtime actually costs the business.

This lesson is for the finance partner who sees a Front Door reliability finding and wants to know what it is really telling them: that a customer-facing service has no automatic failover. It covers why the remediation cost is small and bounded, why the downtime it prevents is open-ended, and how to prioritise the flagged Front Doors by the cost of an hour of each one's outage.

Fun fact

The highly available front end with one place to go

How a finance partner frames the failover decision

Priya is the finance partner supporting the platform team. The reliability report lands with three Front Door findings, each a single origin group. The instinct is not to wave through a blanket resilience budget, it is to ask what an outage of each one actually costs. Front Door does not charge per origin, so adding a second origin to a group is free in Front Door terms; the only real spend is the standby backend itself, and a passive standby can be sized small. The question is therefore narrow: for each flagged service, is the monthly cost of a second origin smaller than the expected cost of the outage it prevents?

Priya asks the team to map each flagged Front Door to the service behind it and the revenue or commitment it carries. One fronts the customer checkout flow, where an hour of downtime is measured in lost orders and SLA credits. One fronts the marketing site, where an outage is embarrassing but not directly costly. One fronts an internal admin tool used by a handful of staff. The finance pack reads: 'Two of three should get a second origin now, because a standby costs a small fixed monthly figure and the checkout outage it prevents is open-ended; the internal tool can be scheduled or accepted as a documented, owned risk.' The framing turns three identical-looking findings into a downtime-cost ranking the business can act on.

Why single-origin Front Doors belong on the risk register

The cost model here is asymmetric in the way reliability work usually is. A second origin is a small, fixed, predictable monthly cost: Front Door charges nothing extra per origin, so it is just the standby backend, which can be sized as a passive instance. Leaving the group at one origin carries an open-ended downtime exposure whose cost lands all at once, at the worst possible time, and is rarely visible on the Azure bill: lost revenue per minute of outage, SLA credits owed to customers, incident-response hours, and the churn and reputational damage that follow a public outage.

The finance role is to attach an expected downtime cost to each flagged Front Door so the work is prioritised by what an outage actually costs, not by the count of findings. A Front Door in front of a revenue-generating flow justifies its standby many times over on the first avoided outage. A Front Door in front of a low-traffic internal tool may be a documented, owned risk rather than an immediate spend. Same finding on the report, very different numbers behind it.

What finance can do about the failover gap

Finance cannot add an origin, but it owns the framing that turns a set of identical-looking reliability findings into a downtime-cost ranking with a small, bounded spend attached to each. Three levers.

1. Make the cost of the fix explicit and bounded

Establish that Front Door does not charge per origin, so the only cost of a second origin is the standby backend, which can be sized as a small passive instance. That turns a vague 'resilience project' into a discrete, forecastable monthly line per service. Nobody should be able to claim that adding failover is an open-ended spend, because it is not.

2. Order the work by the cost of an outage, not the count of findings

A Front Door in front of the checkout flow and one in front of an internal tool both surface as the same single finding, but an hour of their downtime differs by orders of magnitude. Ask the team to attach an expected downtime cost, lost revenue, SLA credits, incident hours, to each flagged service and prioritise by that. The metric for the reliability review is findings weighted by downtime cost, not the raw total.

3. Require a documented, owned decision for any single origin left in place

If a service is genuinely low-value enough to run on a single origin, that should be a recorded, finance-visible decision with an owner, not an unnoticed gap. The difference between 'we accepted this risk deliberately for the internal tool' and 'we never realised the flagship had no failover' is exactly what makes the posture defensible in a resilience review and in the aftermath of any outage.

Quick quiz

Question 1 of 5

Advisor flags three single-origin Front Doors. As the finance partner, what is the right starting assumption about the cost to remediate?

Keep learning

Go deeper on how Azure Front Door uses origins, origin groups, priorities and health probes to deliver automatic failover.

You have finished the finance view of Front Door failover. You know the cost model is one-sided: a second origin is a small fixed monthly cost because Front Door does not charge per origin, while the outage it prevents is open-ended and lands at the worst time. Next time a reliability finding lands, you will rank the flagged Front Doors by the cost of an hour of each one's downtime, fund the standby for the services that warrant it, and require any single origin left in place to be a documented, owned risk.

Back to the library

Multiple origins for Front Door: the headline

Whether a single backend failure can take a customer-facing service fully offline

Front Door is sold and deployed as the highly available global entry point to an application. A single-origin origin group quietly undoes that promise: the edge stays up, but it has exactly one place to send traffic, so a single backend outage becomes a full customer-facing outage with no automatic recovery. Advisor flags this as a High-impact reliability gap for a reason.

The leadership question is not 'is the site up today?' It is 'when one backend fails, and one eventually will, does the service stay up on its own, or does it go dark until an engineer intervenes?' The defensible end state is that every internet-facing Front Door has at least two origins with a primary and a failover, so the cutover is automatic and measured in seconds, not in however long it takes to wake someone up.

This is a downtime-risk decision, not a security one. The trade is a small, bounded monthly cost for a standby origin against the open-ended cost of an outage on a service that customers and revenue depend on. For anything customer-facing, that trade should be easy to approve.

A short read for the leader who needs to know what a single-origin Front Door means in plain terms, why automatic failover is a resilience decision rather than a budget one, and what a defensible end state looks like for every internet-facing service in the estate.

Fun fact

The highly available front end with one place to go

What it looks like when failover is automatic, not a phone call

After a competitor suffered a visible multi-hour outage that made the trade press, the CEO asked the obvious question at the next review: if our main backend fell over right now, what happens? The honest answer at the time was that the service would go down and stay down until an on-call engineer noticed, diagnosed it and repointed traffic, because the Front Door in front of the flagship product had a single origin and nothing to fail over to.

The team's response was to stop treating Front Door as a finished piece of plumbing and start treating it as the resilience layer it is sold as. They added a second origin in a paired region for each customer-facing profile, set the primary to priority 1 and the standby to priority 2, and confirmed that Front Door's health probes detect a dead origin and shift traffic automatically. The next time the CEO asked the question, the answer had changed from 'it stays down until someone fixes it' to 'traffic moves to the standby in seconds, and the on-call engineer gets paged to a degraded service rather than a dead one.' That shift, from recovery that depends on a human being awake to recovery that happens on its own, is the confidence signal this capability delivers, and the cost of it is a small standby backend.

Why this is a board-level reliability risk

Most damaging outages are not exotic, they are a single component failing with nothing behind it to take over. A single-origin Front Door is exactly that pattern in front of your most visible services: the moment the one backend fails, the customer-facing service is down and stays down until a human intervenes. Adding a second origin is the capability that converts that failure mode from a full outage into an automatic, seconds-long cutover.

The cost of getting this wrong is open-ended and arrives at the worst moment, while the cost of fixing it is a small, bounded standby backend. This is the rare class of reliability control where the downside of inaction is severe and unpredictable and the cost of action is small and predictable, which is exactly the trade leadership should be quickest to approve for anything customer-facing.

The leadership move on failover

The executive handle is not to approve each origin individually, it is to require that every internet-facing Front Door has automatic failover and that any single-origin service left in place is a named, owned decision.

1. Set a deadline for automatic failover on customer-facing services

Ask for a date by which every customer-facing Front Door has at least two origins with a primary and a failover, and by which the two-origin pattern is the default in the templates that provision new ones. A failover that happens on its own is the difference between an incident measured in seconds and one measured in however long it takes to wake an engineer.

2. Ask for proof, not assurance

The proof that this is closed is not 'we added a standby.' It is evidence that the failover actually works: a controlled test showing traffic moving to the standby when the primary is taken out of service, plus a clear resolution of the Advisor reliability finding. Ask for the failover test result, not just the configuration change.

3. Treat any remaining single-origin service as a named, owned risk

A small number of low-value services may not justify a standby, and that is a legitimate call. The leadership requirement is that each is a deliberate, documented decision with an owner who accepts the downtime exposure, not an accident. The goal is not failover on everything, it is zero unintended single points of failure in front of services that matter.

Quick quiz

Question 1 of 5

At a board review you ask what happens if the flagship product's backend fails right now. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure Front Door uses origins, origin groups, priorities and health probes to deliver automatic failover.

Two takeaways. A single-origin Front Door is a single point of failure in front of your most visible services, where the cost of inaction is open-ended and the cost of action is a small standby, so it is the resilience trade you should be quickest to approve. And the defensible end state is not 'we added a standby'; it is a proven, tested automatic failover on every customer-facing service, with any remaining single-origin service a named, owned decision rather than an accident.

Back to the library

Part of the learning path Build in Azure resilience

Give Front Door multiple origins for failover

Multiple origins for Front Door: the basics

The highly available front end with one place to go

Finding single-origin Front Doors across a subscription

How Front Door routes around a failed origindeep dive

What is the impact of leaving Front Door on a single origin?

How do you add failover safely?

1. Inventory every single-origin origin group

2. Choose the second origin per service

3. Add the origin and set priorities for active-passive

4. Prove the failover, then bake it into deployment

Quick quiz

Keep learning

Multiple origins for Front Door: the downtime-cost view

The highly available front end with one place to go

How a finance partner frames the failover decision

Why single-origin Front Doors belong on the risk register

What finance can do about the failover gap

1. Make the cost of the fix explicit and bounded

2. Order the work by the cost of an outage, not the count of findings

3. Require a documented, owned decision for any single origin left in place

Quick quiz

Keep learning

Multiple origins for Front Door: the headline

The highly available front end with one place to go

What it looks like when failover is automatic, not a phone call

Why this is a board-level reliability risk

The leadership move on failover

1. Set a deadline for automatic failover on customer-facing services

2. Ask for proof, not assurance

3. Treat any remaining single-origin service as a named, owned risk

Quick quiz

Keep learning

Related site reliability lessons