Site Reliability

Add redundant Traffic Manager endpoints for failover

One capability: make sure every Traffic Manager profile has more than one healthy endpoint, ideally in different regions, so that when one endpoint goes offline the profile fails over instead of taking the application down with it.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Redundant Traffic Manager endpoints: the basics

What does a single-endpoint profile actually put at risk?

Azure Traffic Manager is a DNS-based global load balancer. It does not sit in the data path: it answers DNS queries by handing back the address of a healthy endpoint, chosen by a routing method such as Priority, Performance, Weighted or Geographic. The endpoints behind it are the things that actually serve traffic, an App Service in East US, a public IP in West Europe, an external FQDN at another provider. The profile is only as resilient as the set of endpoints it can choose from.

A profile with exactly one endpoint has nothing to fail over to. Traffic Manager continuously probes each endpoint, and the whole point of that health monitoring is to stop directing users at an endpoint that has stopped answering. With a single endpoint there is no healthy alternative to return, so when that endpoint goes offline the profile goes offline with it. Azure Advisor flags this directly with the reliability recommendation 'Add at least one more endpoint to the profile, ideally in another region', because a one-endpoint profile is a single point of failure wearing the costume of a load balancer.

Most single-endpoint profiles are drift, not intent. A profile stood up around one region with a second region always 'coming next sprint', a failover endpoint that was disabled during an incident and never re-enabled, a profile that quietly lost its second endpoint when a resource group was torn down. The work is to find every profile that cannot fail over, decide where its second endpoint should live, and add a healthy one in a different region so the routing method actually has somewhere to send traffic when the primary stops answering.

In this lesson you will learn how Azure Traffic Manager uses endpoints and health monitoring to fail over, why a single-endpoint profile defeats the entire purpose, how to find every profile that cannot fail over across a subscription, and how to add a redundant endpoint in another region without disrupting live traffic. You will see the exact Advisor recommendation, the az CLI to inventory and remediate, and a Bicep definition that bakes a two-endpoint profile into your infrastructure as code.

Fun fact

The load balancer with nothing to balance to

Traffic Manager fails over at the speed of DNS, not the speed of light. When an endpoint stops answering its health probe, the profile stops returning it, but clients that already resolved the old address keep using it until their cached DNS record expires. Microsoft documents the total failover time as roughly the DNS time-to-live plus the number of tolerated probe failures multiplied by the probing interval. With fast probing and a low TTL that can be well under a minute, but it is never instant. A profile with two endpoints fails over in that window. A profile with one endpoint never fails over at all, because there is no second address to hand out: it simply keeps pointing at something that is no longer there.

Finding profiles that cannot fail over across a subscription

Priya is the platform lead at a SaaS company whose status page took a beating during a regional Azure incident last quarter. Azure Advisor shows a cluster of reliability recommendations telling her to add endpoints to several Traffic Manager profiles.

Rather than open each profile in the portal one at a time, Priya starts by listing every profile alongside how many enabled endpoints it has, so she can separate the genuinely single-endpoint profiles from the ones that are fine.

List every Traffic Manager profile with its endpoint count. Any profile showing a single endpoint cannot fail over.

$ az network traffic-manager profile list --query "[].{name:name, method:trafficRoutingMethod, endpoints:length(endpoints)}" -o table

Name Method Endpoints

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

checkout-prod Priority 1

api-gateway Priority 2

marketing-site Weighted 1

# checkout-prod fronts payments and has ONE endpoint. It cannot fail over. Fix it first.

A profile with one endpoint fronting a revenue-critical service is the highest-value target in this group. Endpoint count, not the recommendation count, is the source of truth.

How Traffic Manager actually fails over, and why one endpoint cannotdeep dive

Traffic Manager works entirely at the DNS layer. A client resolves the profile's name, Traffic Manager applies the routing method to the set of endpoints it currently considers healthy, and returns the address of one of them. It never proxies the traffic itself. Health monitoring drives the whole thing: the service probes each endpoint on the configured protocol, port and path, and an endpoint that fails the probe more times than the tolerated-failures setting is marked Degraded and dropped from the candidate set.

Failover is therefore the act of choosing a different healthy endpoint and handing out its address instead. With Priority routing, traffic goes to the lowest-priority-number endpoint that is healthy, and steps to the next one when that endpoint degrades. None of this can happen with a single endpoint, because the candidate set has one member: when it degrades, there is no other address to return. The total time to recover is documented by Microsoft as roughly the DNS time-to-live plus the tolerated failures multiplied by the probing interval, so a low TTL and fast probing shrink the window but a missing second endpoint makes the window infinite.

This is why Advisor treats the second endpoint, ideally in a different region, as the unit of resilience. Two endpoints in the same region protect against one instance failing but not against the region itself degrading, which is exactly the scenario that produces the worst incidents. Endpoints in different regions give the routing method somewhere genuinely independent to send traffic when a whole region has a bad day, which is the case Advisor's wording calls out specifically.

What is the impact of leaving a profile single-endpoint?

The direct impact is an outage with no automatic recovery. The reason a profile exists is usually to keep a service reachable when something behind it fails. A single-endpoint profile silently removes that property: the moment its one endpoint stops answering, every user resolving the name is sent to something that is not there, and stays sent there until a human notices and intervenes. The health monitoring still runs, but it has nothing healthy to switch to.

The second-order impact is that the failure mode is invisible until it triggers. A two-endpoint profile and a one-endpoint profile look identical on a normal day, both serving traffic happily. The difference only appears during a regional incident or a bad deployment, which is precisely when you least want to discover that the resilience you assumed you had does not exist. The single-endpoint profile is a latent outage waiting for the right bad day.

On the resilience side, every well-architected target for high availability, whether your own SLA commitments to customers or an internal availability objective, assumes that a single component or region failing does not take the service down. A Traffic Manager profile that cannot fail over breaks that assumption at the one layer specifically responsible for upholding it. A passing set of multi-endpoint, multi-region profiles is the cheapest, most direct evidence that your front door can survive a regional failure.

How do you add redundancy without disrupting live traffic?

Work the capability as one loop rather than chasing individual recommendations. The order matters: stand up and verify the new endpoint before you rely on it, so you add resilience without introducing a new way to break.

1. Inventory every profile by endpoint count

List every Traffic Manager profile with how many enabled endpoints it has and which routing method it uses. Treat the endpoint count as the source of truth, not the Advisor recommendation count, and note which profiles front customer-facing or revenue-critical services so you can prioritise them.

2. Decide where the second endpoint lives

For each single-endpoint profile, choose a second region for the standby. A different region, not just a different instance in the same region, is what protects against a regional failure, which is the scenario Advisor calls out. The standby can be a warm copy, a smaller tier, or an external endpoint, sized to what the service is worth and how fast it must take over.

3. Add the endpoint and verify it is healthy first

Create the second endpoint and confirm Traffic Manager probes it as Online before you depend on it. With Priority routing, give the existing endpoint priority 1 and the standby priority 2, so live traffic stays on the primary and only fails over when the primary degrades. Adding a healthy endpoint does not move traffic off a working primary, so this step is safe to do in production.

4. Bake the two-endpoint shape into infrastructure as code

Define the profile with both endpoints in Bicep or your IaC of choice so the redundant shape is the default for anything created from it, and so a profile cannot silently drift back to a single endpoint. Pair this with a low DNS TTL and fast probing where quick failover matters, so the recovery window is as short as the design allows.

# Add a redundant second endpoint to a single-endpoint Priority profile.
# The existing primary stays at priority 1; the standby is added at priority 2,
# so live traffic is NOT moved off the working primary.
RG="rg-frontdoor"
PROFILE="checkout-prod"
STANDBY_ID=$(az webapp show \
  --name checkout-westeurope \
  --resource-group "$RG" \
  --query id -o tsv)

az network traffic-manager endpoint create \
  --name checkout-westeurope \
  --resource-group "$RG" \
  --profile-name "$PROFILE" \
  --type azureEndpoints \
  --target-resource-id "$STANDBY_ID" \
  --priority 2 \
  --endpoint-status Enabled

# Confirm Traffic Manager sees the new endpoint as healthy before relying on it.
az network traffic-manager endpoint show \
  --name checkout-westeurope \
  --resource-group "$RG" \
  --profile-name "$PROFILE" \
  --type azureEndpoints \
  --query "{status:endpointStatus, monitor:endpointMonitorStatus}" -o table

Quick quiz

Question 1 of 5

Azure Advisor recommends adding at least one more endpoint to a Traffic Manager profile, ideally in another region. Why does a single-endpoint profile defeat the purpose of Traffic Manager?

Keep learning

Go deeper on how Traffic Manager chooses endpoints, monitors their health, and how quickly it can fail over.

You can now treat Traffic Manager redundancy as one capability rather than a scatter of recommendations: inventory every profile by endpoint count, decide where each standby should live, add a healthy second endpoint in a different region without disrupting the live primary, and bake the two-endpoint shape into infrastructure as code so it cannot drift back. A profile that can fail over is the difference between a regional incident being a blip and being an outage.

Back to the library

Redundant Traffic Manager endpoints: the cost-of-downtime view

A near-zero-cost change that removes a whole class of avoidable outage

A single-endpoint Traffic Manager profile is a cost question dressed as a configuration setting. The profile itself is billed on DNS queries and health checks, which is a small, steady cost. The expensive item is the outage it cannot prevent: when the one endpoint goes down, the application is down, and the bill for that arrives as lost revenue, missed transactions, breached service commitments and the support and engineering hours spent restoring service under pressure.

Frame the failing recommendation as a line on the risk register, not a compliance checkbox. The cost of resilience here is genuinely small: a second endpoint means running a standby in another region, and depending on the application that can be a warm copy you already pay for, a smaller standby tier, or even an external endpoint at another site. Traffic Manager does not charge meaningfully more for monitoring a second endpoint. The comparison is between a bounded, predictable monthly cost for the standby and the unbounded, unpredictable cost of an outage you had no way to route around.

The arithmetic is one-sided for any profile that fronts something users actually depend on. The remediation is the running cost of a second endpoint plus the engineering time to stand it up. The downside of leaving it is the documented cost of downtime for that application: lost revenue per hour, service-credit liabilities, and the reputational cost of being unreachable while a single region recovers on its own schedule.

This lesson is for the finance partner who sees a reliability recommendation about Traffic Manager endpoints and wants to know what the right response is and what it costs. It covers why the change is cheap relative to the outage it prevents, how to size the cost of a standby endpoint, and how to weigh that against the cost of downtime for the service the profile fronts.

Fun fact

The load balancer with nothing to balance to

How a finance partner frames the endpoint decision

Priya is the finance partner supporting the platform team after the regional incident that knocked the checkout flow offline for most of an afternoon. Advisor lands with reliability recommendations on several Traffic Manager profiles, and the instinct is not to wave through a blanket second-region budget; it is to ask what each profile actually fronts. A profile in front of the payments service and a profile in front of an internal status dashboard both surface as the same recommendation, but the cost of them being down differs by orders of magnitude.

Priya asks the team to map each single-endpoint profile to the revenue or operation behind it, and to size the standby honestly. The checkout profile needs a genuine warm second region, a real running cost, because every hour it is unreachable has a measurable revenue number attached from last quarter's incident. The marketing site can fail over to a cheap static copy or an external endpoint for a few pounds a month. The internal dashboard may not justify a standby at all and can carry a documented exception. The finance pack reads: 'One profile fronts revenue and gets a funded warm standby that pays for itself against one avoided outage; two profiles get cheap redundancy; one is a documented accept-the-risk. The spend is bounded and sized to what each service is worth, not to the count of recommendations.'

Why a single-endpoint profile belongs on the risk register

The cost model here is asymmetric in the way reliability spend usually is. A second endpoint is a bounded, forecastable monthly cost: a standby tier or an external endpoint plus a negligible amount of extra Traffic Manager monitoring. Leaving the profile single-endpoint creates an unbounded tail risk: the cost of the application being unreachable for as long as one region takes to recover, with no way to route around it.

The documented cost of downtime for a customer-facing service includes lost revenue per hour, service credits or SLA penalties owed to customers, support and incident-response hours, and the harder-to-quantify reputational damage of being unreachable. Against that, the remediation is the running cost of a standby endpoint sized to what the service is worth. The finance role is to attach a cost-of-downtime figure to each single-endpoint profile so the work is prioritised by the value of the service it fronts, not by the order Advisor lists the recommendations, and so the standby for a revenue-critical profile is funded as the cheap insurance it is.

What finance can do about the redundancy gap

Finance cannot add an endpoint, but it owns the framing that turns a list of reliability recommendations into a risk-ordered plan with a bounded, sized cost and a clearly documented set of exceptions. Three levers.

1. Size the standby to the cost of downtime, not to the recommendation

Make explicit that the cost of a second endpoint should be sized to what the service it fronts is worth. A revenue-critical profile justifies a funded warm standby in another region, because one avoided outage pays for it many times over. A low-stakes internal profile justifies a cheap external endpoint or a small static copy. Budget each as a discrete line tied to a cost-of-downtime figure, so nobody treats the whole capability as one blanket spend or dismisses it as gold-plating.

2. Order the work by cost of downtime, not by recommendation count

A profile fronting payments and a profile fronting an internal dashboard both surface as the same Advisor recommendation, but their cost of downtime differs by orders of magnitude. Ask the team to attach an hourly cost-of-downtime estimate to each single-endpoint profile and remediate the highest first. The metric that belongs on the reliability and cost review is single-endpoint profiles weighted by the value of the service they front, not the raw recommendation total.

3. Require documented exceptions for profiles you deliberately leave single-endpoint

Some profiles genuinely do not justify a standby: a throwaway demo, an internal tool nobody is paged for. Any profile left single-endpoint on purpose should carry a recorded, finance-visible reason and an accepted cost of downtime. The distinction between 'we reviewed this and accepted the risk' and 'we never noticed it had one endpoint' is exactly what makes the posture defensible when a region does fail.

Quick quiz

Question 1 of 5

Advisor flags several single-endpoint profiles. As the finance partner, how should the cost of a second endpoint be sized?

Keep learning

Go deeper on how Traffic Manager chooses endpoints, monitors their health, and how quickly it can fail over.

You have finished the finance view of Traffic Manager redundancy. You know the cost model is one-sided for any profile that fronts something users depend on: a standby is a bounded, forecastable cost, while the outage it prevents is unbounded and well documented. Next time a reliability recommendation lands, you will size each standby to the cost of downtime of the service it fronts, order the work by that figure rather than by recommendation count, and put the deliberate single-endpoint profiles on the record as accepted exceptions.

Back to the library

Redundant Traffic Manager endpoints: the headline

Whether a customer-facing service can survive one region having a bad day

Traffic Manager is the thing that is supposed to keep an application reachable when a region, a data centre or a single deployment fails. A profile with only one endpoint quietly removes that protection: it looks like a load balancer on the architecture diagram, but it has nothing to balance to. The report shows this as a scatter of single-endpoint profiles across the estate, each one a service that cannot fail over.

The leadership question is not 'do we have Traffic Manager?' It is 'if one region goes offline tomorrow, does the customer notice?' The defensible end state is that every profile fronting a service users depend on has at least two healthy endpoints in different regions, so a single regional failure is a non-event rather than an outage.

This is a resilience decision with a small and predictable price tag. A standby endpoint costs something to run, but it is a bounded, forecastable cost. The alternative is accepting that any single point of failure can take a customer-facing service down, and discovering which services those are at the worst possible moment.

A short read for the leader who needs to know what a single-endpoint profile actually exposes, why adding redundancy is a resilience decision with a bounded cost, and what a defensible end state looks like for the services customers depend on.

Fun fact

The load balancer with nothing to balance to

What it looks like when a region failure is a non-event

After the checkout flow went dark for an afternoon during a regional Azure incident, with the status page red and the revenue dashboard flat, the CEO asked the obvious question at the next review: why did one region's problem become our outage? The honest answer was that the profile in front of checkout had a single endpoint in that region, so when the region degraded there was nothing for Traffic Manager to fail over to. The load balancer on the diagram had nothing to balance to.

The team's response was to stop treating Traffic Manager as a box on the diagram and start treating endpoint redundancy as a guardrail. They listed every profile, identified the ones fronting customer-facing services that had only one endpoint, and stood up a second endpoint in a different region for each, primary at priority one and standby at priority two. The next time a single region had a bad day, the failover happened in the time it took DNS records to expire, and the only evidence was a blip on a latency graph. The shift, from 'a single region's problem is our outage' to 'a single region's problem is a non-event', is the confidence signal this capability delivers, and for most profiles the price is a modest, predictable standby.

Why this is a board-level resilience risk

Nearly every avoidable outage that traces back to 'one region had a problem' comes down to the same root cause: a layer that was supposed to fail over could not, because it had nowhere to fail over to. A single-endpoint Traffic Manager profile is exactly that root cause, sitting at the front door of a service. Adding a second endpoint in another region is the capability that turns a regional failure from an outage into a blip.

The cost of getting this wrong is the well-understood cost of downtime for the service, which for anything customer-facing is large and arrives without warning. The cost of fixing it is the modest, predictable price of running a standby. This is the kind of resilience trade leadership should be quickest to approve: a small, known monthly cost to retire a large, unknown one.

The leadership move on Traffic Manager redundancy

The executive handle is not to approve each endpoint individually; it is to require that every profile fronting a service customers depend on can survive a regional failure, and that the few deliberate single-endpoint exceptions are named and owned.

1. Set a deadline to reach a multi-region end state

Ask for a date by which every profile fronting a customer-facing or revenue-critical service has at least two healthy endpoints in different regions, baked into infrastructure as code so it cannot drift back. A two-endpoint, two-region front door is the difference between a regional incident being an outage and being a blip.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we added some endpoints.' It is a list of every profile with its endpoint count and the regions those endpoints sit in, plus evidence that a failover test actually moved traffic to the standby. A standby that has never been verified as healthy is a standby you do not yet have.

3. Treat the deliberate single-endpoint profiles as named, owned exceptions

A few profiles will not justify a standby, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and an accepted cost of downtime, not a profile nobody looked at. The goal is not zero single-endpoint profiles; it is zero unintended ones in front of services that matter.

Quick quiz

Question 1 of 5

At a board review after a regional incident, you ask whether a single region's failure could take a customer-facing service down again. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Traffic Manager chooses endpoints, monitors their health, and how quickly it can fail over.

Two takeaways. A single-endpoint Traffic Manager profile is a latent outage: it looks fine until a region has a bad day, which is exactly when you find out the failover you assumed you had does not exist. And the defensible end state is not 'we added some endpoints'; it is every profile fronting a service customers depend on having two healthy endpoints in different regions, baked into infrastructure as code and proven with a failover test, so a regional failure is a non-event.

Back to the library

Part of the learning path Build in Azure resilience

Add redundant Traffic Manager endpoints for failover

Redundant Traffic Manager endpoints: the basics

The load balancer with nothing to balance to

Finding profiles that cannot fail over across a subscription

How Traffic Manager actually fails over, and why one endpoint cannotdeep dive

What is the impact of leaving a profile single-endpoint?

How do you add redundancy without disrupting live traffic?

1. Inventory every profile by endpoint count

2. Decide where the second endpoint lives

3. Add the endpoint and verify it is healthy first

4. Bake the two-endpoint shape into infrastructure as code

Quick quiz

Keep learning

Redundant Traffic Manager endpoints: the cost-of-downtime view

The load balancer with nothing to balance to

How a finance partner frames the endpoint decision

Why a single-endpoint profile belongs on the risk register

What finance can do about the redundancy gap

1. Size the standby to the cost of downtime, not to the recommendation

2. Order the work by cost of downtime, not by recommendation count

3. Require documented exceptions for profiles you deliberately leave single-endpoint

Quick quiz

Keep learning

Redundant Traffic Manager endpoints: the headline

The load balancer with nothing to balance to

What it looks like when a region failure is a non-event

Why this is a board-level resilience risk

The leadership move on Traffic Manager redundancy

1. Set a deadline to reach a multi-region end state

2. Ask for proof, not assurance

3. Treat the deliberate single-endpoint profiles as named, owned exceptions

Quick quiz

Keep learning

Related site reliability lessons