Monitoring

Keep Traffic Manager endpoint monitoring healthy

One capability across every Traffic Manager profile: make sure endpoint health monitoring is actually online, because a degraded probe means failover cannot be trusted and you are routing live traffic blind.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Traffic Manager monitor status: the basics

What does a degraded Traffic Manager profile actually mean?

Azure Traffic Manager is a DNS-based global load balancer. It does not sit in the data path; it answers DNS queries and hands the client the address of a healthy endpoint. The only thing that lets it know which endpoint is healthy is its endpoint monitoring: a periodic health probe to each endpoint. When that monitoring is online, Traffic Manager can pull a failing region out of DNS and send users somewhere that works. When the monitoring itself is degraded, that promise quietly stops being true.

Each profile carries a monitor status and each endpoint inside it carries its own. The values you will see are Online, Degraded, CheckingEndpoint, Unmonitored, Disabled, Inactive and Stopped. Online is the only state in which failover is fully trustworthy. Degraded means one or more endpoints failed their probe; the profile keeps routing, but to fewer endpoints than you think. The states that catch teams out are the quiet ones: an endpoint left Disabled, a probe pointed at a path that no longer returns 200, or a firewall that started blocking the probe IPs so every endpoint reads Degraded at once.

Azure Advisor raises this as a reliability recommendation, 'Traffic Manager profiles should have endpoint monitoring enabled' and the related guidance that the monitor status should be online, precisely because a degraded monitor is invisible until the day you need failover. The work in this lesson is to find every profile whose monitor status is not Online, understand why the probe is failing, and fix the probe configuration or the path it depends on so that health monitoring tells you the truth before an incident does.

In this lesson you will learn how Azure Traffic Manager monitoring works, how a profile or endpoint ends up Degraded without anyone touching it, how to find every profile whose monitor status is not Online, and how to fix the probe configuration so failover can be trusted again. You will also see how to add an alert so a degraded monitor tells you in seconds instead of waiting for the next incident.

Fun fact

The probe that watched a redirect

Traffic Manager treats an HTTP redirect as a probe failure by default. It sends a GET and expects a 200 directly, so the day a team adds an HTTP-to-HTTPS redirect, or a path starts returning a 301 to a login page, every endpoint behind that profile can flip to Degraded even though the application is perfectly healthy. The application is up, users are fine, and yet failover is now disabled because Traffic Manager believes nothing is online. It is one of the most common ways a monitor goes dark without a single endpoint actually being down, and it is why the probe path has to point at something that returns a flat 200, not at the front door of the app.

Finding degraded monitoring across the estate

Priya runs the platform team at a retailer whose checkout is fronted by Traffic Manager across two regions. Azure Advisor has flagged a reliability recommendation that a profile's endpoint monitor status is not online, and she wants to know which profiles are affected and why before the next peak sales weekend.

Rather than open each profile in the portal, she lists every endpoint and its monitor status in one pass, so a probe that is quietly lying can be separated from an endpoint that is genuinely down.

List every endpoint in a profile with its monitor status. Anything that is not Online needs a reason.

$ az network traffic-manager endpoint list \ --resource-group shop-prod-rg \ --profile-name shop-checkout-tm \ --query "[].{endpoint:name, status:monitorStatus, enabled:endpointStatus}" -o table

Endpoint Status Enabled

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

checkout-weu Degraded Enabled

checkout-neu Online Enabled

# checkout-weu is Enabled but Degraded: the probe is failing, so failover excludes it. Find out why before peak.

An endpoint that is Enabled but Degraded is the dangerous case: Traffic Manager has silently removed it from DNS, so you are running on one region without intending to. Investigate the probe before peak load, not during it.

How Traffic Manager decides an endpoint is degradeddeep dive

Traffic Manager runs a probe against each enabled endpoint from a set of probing agents around the world. The probe is defined by the profile's monitor configuration: a protocol (HTTP, HTTPS or TCP), a port, and for HTTP and HTTPS a path. For HTTP and HTTPS it sends a GET and expects a 200 by default, although you can widen this with an expected-status-code-ranges setting. For TCP it just expects the handshake to complete. The interval, the per-probe timeout, and the number of consecutive failures tolerated before the endpoint flips to Degraded are all part of that same configuration.

An endpoint goes Degraded for one of a few concrete reasons. The path returns something other than the expected status, which most often means a redirect: Traffic Manager treats a 301 or 302 as a failure unless you have explicitly allowed that code range. The probe times out because the endpoint is slow or unreachable. Or a firewall or network security group in front of the endpoint is dropping the probe traffic, in which case every endpoint behind it reads Degraded at once. The fix for that last case is to allow the AzureTrafficManager service tag rather than chase a hand-maintained list of probe IPs, because Microsoft updates the service tag automatically.

Two values matter when you read the status. The endpoint status (enabled or disabled) is whether you have told Traffic Manager to consider the endpoint at all. The monitor status (Online, Degraded, CheckingEndpoint and so on) is the live probe result for the ones that are enabled. An endpoint that is enabled but degraded is silently out of rotation; an endpoint that is disabled was taken out deliberately. Advisor's reliability recommendation keys off the profile and endpoint not being in the Online state, which is why a single misconfigured probe path can light up the recommendation across every profile that shares it.

What is the impact of a degraded monitor?

The direct impact is that failover stops being trustworthy. Traffic Manager only routes around a region it knows is unhealthy, and it only knows that through the probe. If the monitor is degraded because the probe is misconfigured, two things can happen and both are bad. A healthy endpoint can be pulled out of DNS because the probe is failing for a configuration reason, shrinking your capacity for no real cause. Or, more dangerously, you lose confidence that a genuinely failing region would be detected at all, so the automatic failover you designed and pay for may never fire.

The second-order impact is on mean-time-to-detect and mean-time-to-resolve. When monitoring is healthy, a regional failure is detected by the probe in seconds and routed around automatically; the incident is often resolved before a human is involved. When the monitor is degraded, that whole loop is broken, and the first detection signal becomes a customer report, a support spike or a revenue dip. Every minute spent flying blind is a minute of outage that a working monitor would have collapsed to near zero, and it is also a minute of slower diagnosis because the one system that should have pointed at the failing region is itself untrustworthy.

There is a reliability-evidence angle too. Azure Advisor surfaces this as a reliability recommendation, and any serious resilience review, a well-architected assessment, a disaster-recovery audit or an internal game-day, expects evidence that health monitoring across your global routing is actually online. A profile reporting Online with an alert wired to its monitor status is the cheapest and most defensible artefact that your failover is real and not just drawn on a diagram.

How do you get monitoring back to online safely?

Work it as one loop rather than chasing the Advisor item once. The order matters: understand why each probe is failing before you change anything, so you fix the real cause rather than masking it by widening the probe until it passes.

1. Inventory every profile by monitor status

List every Traffic Manager profile and endpoint and its monitor status. Treat anything not Online as a finding: Degraded, CheckingEndpoint that never settles, or Unmonitored where you expected monitoring. This inventory, not the single Advisor item, is the source of truth, because one shared probe path can degrade several profiles at once.

2. Diagnose the real cause of each degraded probe

For each degraded endpoint, find out why the probe fails. Curl the probe path yourself and check the status code: a redirect (301 or 302) is the most common culprit, followed by a path that returns 404 or 500, a timeout from a slow endpoint, or a firewall dropping the probe. Decide whether the application is genuinely unhealthy or the probe is pointed at the wrong thing.

3. Fix the probe, not the symptom

Point the probe at a dedicated, flat health path that returns a 200 with no redirect, on the right protocol and port. Where the endpoint sits behind a firewall or NSG, allow the AzureTrafficManager service tag so probe traffic is never dropped. Only widen the expected status code range if a non-200 is genuinely a healthy response for that endpoint; do not widen it just to make the finding disappear.

4. Alert on monitor status so it never goes dark silently

Wire an Azure Monitor metric alert to the Traffic Manager endpoint health metric, or a Resource Graph check on a schedule, so any profile dropping out of Online raises an alert within minutes. This is what converts the control from a point-in-time fix into a standing guarantee that a degraded monitor tells you, rather than waiting to be discovered during the next incident.

# 1. Find every endpoint across the subscription whose monitor status is not Online.
az graph query -q "resources
  | where type == 'microsoft.network/trafficmanagerprofiles'
  | mv-expand endpoint = properties.endpoints
  | extend status = tostring(endpoint.properties.endpointMonitorStatus)
  | where status != 'Online' and status != 'Disabled'
  | project profile = name, endpoint = tostring(endpoint.name), status, resourceGroup" \
  -o table

# 2. Repoint the profile probe at a flat health path that returns 200 (no redirect),
#    over HTTPS, with sensible interval/timeout/failure tolerance.
az network traffic-manager profile update \
  --resource-group shop-prod-rg \
  --name shop-checkout-tm \
  --protocol HTTPS \
  --port 443 \
  --path /healthz \
  --interval 30 \
  --timeout 10 \
  --max-failures 3

# 3. Alert when any profile leaves the Online state, so it never degrades silently.
az monitor metrics alert create \
  --name tm-checkout-degraded \
  --resource-group shop-prod-rg \
  --scopes "$(az network traffic-manager profile show -g shop-prod-rg -n shop-checkout-tm --query id -o tsv)" \
  --condition "min ProbeAgentCurrentEndpointStateByProfileResourceId < 1" \
  --description "A Traffic Manager endpoint left the Online state"

Quick quiz

Question 1 of 5

Azure Advisor flags that a Traffic Manager profile's endpoint monitor status is not online. Why does this matter even though the application is still serving users?

Keep learning

Go deeper on how Traffic Manager monitoring works and how the monitor configuration controls when an endpoint is considered degraded.

You can now treat Traffic Manager monitoring as a capability rather than a one-off Advisor item: inventory every profile whose monitor status is not Online, diagnose why each probe is failing instead of masking it, fix the probe at its real cause (most often a redirect, a wrong path or a firewall blocking probe traffic), and wire an alert so a degraded monitor tells you in minutes rather than during the next incident. Healthy monitoring is what makes your failover real.

Back to the library

Traffic Manager monitor status: the visibility and cost-of-blindness view

A near-zero-cost capability that protects mean-time-to-detect and avoids the cost of flying blind during an outage

Fixing a degraded Traffic Manager monitor costs nothing in Azure spend. You are correcting a probe path, a port, a protocol or a firewall rule, not buying a bigger SKU. The cost that matters here is the cost of not knowing: when monitoring is degraded, your first signal that a region is down is a customer complaint or a revenue dip, not an automated failover. That gap, the time between something breaking and anyone noticing, is mean-time-to-detect, and it is where outage cost accumulates.

Frame each degraded profile as a hole in your detection coverage rather than a tidy compliance tick. A Traffic Manager profile that fronts a checkout flow but reports Degraded is not a low-value finding; it is the difference between failing over in seconds and discovering the outage in the next day's sales numbers. Map degraded monitors to the revenue or service behind them and prioritise by what goes dark when the probe is lying.

The arithmetic is one-sided. The remediation is engineering time to fix a probe configuration. The downside of leaving it is the fully loaded cost of an undetected outage: lost transactions for the duration, the support and engineering hours burned diagnosing it the slow way, and the SLA credits or reputational cost of customers finding the failure before you did.

This lesson is for the finance partner who sees a Traffic Manager reliability recommendation on the Advisor report and wants to know what it costs and why it matters. It covers why fixing it is free in Azure spend, why a degraded monitor is really a gap in outage detection, and how to prioritise degraded profiles by the revenue and service they front rather than by the raw finding count.

Fun fact

The probe that watched a redirect

How a finance partner frames the degraded monitor

Priya is the finance partner sitting with the platform team ahead of the peak sales weekend. The Advisor report carries a reliability recommendation that a Traffic Manager monitor status is not online, and the instinct is not to ask what it costs to fix, because the answer is nothing in Azure spend. The instinct is to ask what is behind the profile. This one fronts checkout. A degraded monitor on the checkout profile means that if the primary region wobbles during peak, the automatic failover that is supposed to make it a non-event may not fire, and the first signal would be a dip in completed orders.

Priya reframes the finding from a reliability checkbox into a detection-coverage gap with a revenue number attached. She asks the team for two things: which profiles are degraded, and what each one fronts. Three profiles are flagged. One fronts a low-traffic internal tool, one fronts a marketing microsite, and one fronts checkout. The finance pack reads: 'All three cost nothing in Azure spend to fix. Two are low-impact and can be scheduled. The checkout profile is the one that matters, because a degraded monitor there means an undetected regional outage during peak directly costs completed orders for the duration. Fix that one before the weekend; the rest are engineering hygiene.'

Why a degraded monitor belongs on the operational-risk register

The cost model here is asymmetric in the same way good monitoring usually is. Fixing a degraded monitor costs nothing in Azure spend, and leaving it broken creates an unbounded tail risk: an outage you detect late. The probability of a regional failure on any given day is low, but the cost when it lands and your detection is blind is high, and it scales with the length of time you stay blind.

The documented cost of an undetected outage is concrete: lost transactions for the full duration, the engineering and support hours burned diagnosing a failure the slow way because the monitor that should have pointed at it was lying, and any SLA credits owed to customers who found the failure before you did. Against that, the remediation is engineering time to correct a probe path or a firewall rule. The finance role is to attach an expected-loss-per-hour-of-blindness figure to each degraded profile so the work is prioritised by the revenue it protects, not by the order Advisor lists it.

What finance can do about a degraded monitor

Finance cannot repoint a probe, but it owns the framing that turns a reliability finding into a risk-ordered plan with no incremental Azure spend and a clear revenue case. Three levers.

1. Make explicit that the fix is free and the risk is the cost

State plainly that getting a Traffic Manager monitor back to online costs nothing in Azure spend: it is a probe path, a firewall rule or an alert, not a bigger SKU. The cost lives entirely in leaving it broken, where it shows up as the expected loss of an undetected outage. Budget the work as engineering time and keep the conversation on the revenue at risk, so nobody treats a free fix as a spending decision to defer.

2. Order the work by revenue behind the profile, not by finding count

A degraded monitor on an internal tool and a degraded monitor on checkout both appear as one reliability item, but their expected loss differs by orders of magnitude. Ask the team to map each degraded profile to what it fronts and prioritise by revenue exposed per hour of undetected outage. The metric that belongs on the operational review is degraded profiles weighted by the revenue and service they protect, not the raw count.

3. Treat mean-time-to-detect as a tracked number

The point of healthy monitoring is a short time-to-detect for a regional outage. Ask for that to be a standing metric: every critical profile reports online, and an alert exists so a degradation is detected in minutes. A bounded, evidenced time-to-detect is what lets finance put a defensible ceiling on the cost of any future regional failure, rather than treating it as an open-ended unknown.

Quick quiz

Question 1 of 5

Advisor flags a degraded Traffic Manager monitor. As the finance partner, what is the right starting assumption about the Azure-spend cost to fix it?

Keep learning

Go deeper on how Traffic Manager monitoring works and how the monitor configuration controls when an endpoint is considered degraded.

You have finished the finance view of Traffic Manager monitoring. The cost model is one-sided: fixing a degraded monitor is free in Azure spend, and the real cost is the undetected outage you risk by leaving it broken. Next time a reliability finding lands, you will order degraded profiles by the revenue they front, treat mean-time-to-detect as a tracked number, and keep the conversation on the loss avoided rather than on a fix that costs nothing.

Back to the library

Traffic Manager monitor status: the headline

Whether the system that is supposed to detect a regional outage and route around it is actually watching

Traffic Manager is one of the controls you are paying for to make a regional failure a non-event for customers. It can only do that if its health monitoring is online. A degraded monitor means the safety net is there on the architecture diagram but not in practice, and nobody finds out until an outage that should have been invisible becomes a visible one.

The leadership question is not 'do we have failover?' It is 'if a region fails tomorrow, will we detect it and route around it automatically, or will we hear about it from customers first?' The defensible end state is that every Traffic Manager profile reports an online monitor status, that a degraded probe raises an alert the moment it happens, and that the time to detect a regional outage is measured in seconds rather than discovered by accident.

This is not a budget decision. Keeping endpoint monitoring healthy is essentially free in Azure terms. It is a question of whether your outage detection is something you verify and watch, or something you assume is working until the day it isn't.

A short read for the leader who needs to know what a degraded Traffic Manager monitor reveals: that the automatic outage detection you are relying on may not be working, why fixing it is a visibility decision rather than a budget one, and what a defensible end state for mean-time-to-detect looks like across the estate.

Fun fact

The probe that watched a redirect

What it looks like when outage detection is verified, not assumed

After a competitor lost a day of online sales to a regional outage that their failover should have caught, the CEO asked the obvious question at the next review: if a region fails during our peak weekend, do we actually detect it and route around it, or do we find out from customers? The honest answer at the time was that it depended on whether the Traffic Manager monitoring was healthy, and nobody had checked, because a degraded probe is invisible until you need it.

The team's response was to stop assuming the safety net worked and start verifying it. They listed every profile whose monitor status was not Online, found that the checkout profile was Degraded because a recently added HTTPS redirect was breaking the probe, repointed the probe at a flat health path that returns 200, and added an alert so any future degraded monitor pages someone within minutes. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'every profile reports online, and if one goes degraded we are paged before customers notice.' That shift, from assuming the detection works to proving it and watching it, is the confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Why this is a board-level reliability question

Almost every avoidable extended outage shares a root cause: the failure happened and the detection that should have caught it was not working. A degraded Traffic Manager monitor is exactly that condition for your global routing, the safety net is present on the diagram but not in operation. Getting every profile to an online monitor status, and alerting when one degrades, is what turns a regional failure from a visible, customer-facing incident into a non-event.

The cost of getting this wrong is large and measured in lost revenue and reputational damage during the window you were blind. The cost of getting it right is essentially engineering time. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should approve fastest.

The leadership move on monitor status

The executive handle is not to approve a probe fix; it is to require that outage detection across global routing is verified and watched, with a measured time-to-detect, rather than assumed.

1. Require every critical profile to report online, with proof

Ask for a date by which every Traffic Manager profile fronting a customer-facing or revenue-bearing service reports an online monitor status, with the evidence being the live status, not a verbal 'we fixed it.' A profile that is online is a failover path you can trust; one that is degraded is a safety net that exists only on the diagram.

2. Insist on an alert, not a one-time check

A point-in-time fix degrades again the next time someone adds a redirect or tightens a firewall. The durable requirement is an alert wired to monitor status, so any profile leaving the online state pages someone within minutes. The difference between checking once and alerting always is the difference between hoping detection works and knowing it does.

3. Make time-to-detect a reliability metric you review

Treat the time to detect a regional outage as a number you see at the operational review, not a hope. The goal is that a region failing is detected and routed around in seconds, automatically, with humans informed rather than relied upon to notice. That is the concrete outcome a healthy Traffic Manager monitor underwrites, and it is what turns a potential outage into a non-event.

Quick quiz

Question 1 of 5

At a review you ask whether a regional failure during peak would be detected and routed around automatically. What end state is the defensible answer?

Keep learning

Go deeper on how Traffic Manager monitoring works and how the monitor configuration controls when an endpoint is considered degraded.

Two takeaways. A degraded Traffic Manager monitor means the automatic outage detection you rely on may not be working, and fixing it is essentially free, so it is the trade you should approve fastest. And the defensible end state is not 'we checked once'; it is every critical profile reporting online, an alert that pages the moment one degrades, and a regional outage detected and routed around in seconds rather than discovered by customers.

Back to the library

Part of the learning path See what Azure is doing

Keep Traffic Manager endpoint monitoring healthy

Traffic Manager monitor status: the basics

The probe that watched a redirect

Finding degraded monitoring across the estate

How Traffic Manager decides an endpoint is degradeddeep dive

What is the impact of a degraded monitor?

How do you get monitoring back to online safely?

1. Inventory every profile by monitor status

2. Diagnose the real cause of each degraded probe

3. Fix the probe, not the symptom

4. Alert on monitor status so it never goes dark silently

Quick quiz

Keep learning

Traffic Manager monitor status: the visibility and cost-of-blindness view

The probe that watched a redirect

How a finance partner frames the degraded monitor

Why a degraded monitor belongs on the operational-risk register

What finance can do about a degraded monitor

1. Make explicit that the fix is free and the risk is the cost

2. Order the work by revenue behind the profile, not by finding count

3. Treat mean-time-to-detect as a tracked number

Quick quiz

Keep learning

Traffic Manager monitor status: the headline

The probe that watched a redirect

What it looks like when outage detection is verified, not assumed

Why this is a board-level reliability question

The leadership move on monitor status

1. Require every critical profile to report online, with proof

2. Insist on an alert, not a one-time check

3. Make time-to-detect a reliability metric you review

Quick quiz

Keep learning

Related monitoring lessons