Azure Traffic Manager Not Working, Connectivity, Rules, and Routing Fixes
Why Azure Traffic Manager Is Not Working
You set up Azure Traffic Manager carefully, endpoints configured, routing method selected, profile published. Then you check the portal and see it: a red Degraded status badge staring back at you. Or worse, traffic just isn't going where you told it to go, and you have no idea why. I've seen this exact situation on dozens of enterprise deployments, and every single time the root cause turned out to be something the Azure portal's error message barely hinted at.
Azure Traffic Manager not working correctly usually comes down to one of three categories: probe failures, misconfigured routing rules, or endpoint health misreading. The tricky part is that Traffic Manager's own status display can sometimes make things look worse, or different, than they actually are.
Here's the core thing to understand: Traffic Manager considers an endpoint ONLINE only when its health probe receives an HTTP 200 response from the probe path you configured. Not 201. Not 301. Not 404. A plain 200. If your application returns anything else, even a perfectly normal redirect, Traffic Manager marks that endpoint as Offline or Degraded, and it stops routing traffic there. This catches a lot of people off guard because, from a browser's perspective, a 301 redirect works fine. From Traffic Manager's probe perspective, it's a hard failure.
The Degraded status means at least one endpoint in your profile has gone offline, but not all of them. The Inactive status is more serious: it typically means all endpoints in the profile are disabled, either manually or because the profile itself is disabled. Understanding which state you're actually in changes everything about how you troubleshoot.
There's also a counterintuitive safety behavior worth knowing: if every single endpoint in a profile degrades simultaneously, Traffic Manager will actually start routing traffic to all of them anyway. This is intentional, it protects against a situation where a broken probing mechanism would otherwise cause a complete service outage. So if you're seeing traffic hit a supposedly-offline endpoint, this might be exactly why.
Who runs into Azure Traffic Manager degraded status problems most often? Cloud architects migrating legacy apps to Azure, teams running multi-region failover setups for the first time, and developers who set up Traffic Manager quickly without fully configuring probe paths. It doesn't mean you did something wrong, the defaults aren't always safe for production workloads, and the documentation assumes a lot of background knowledge.
The Quick Fix, Try This First
Before you spend an hour digging through logs, try this: manually test your probe URL right now and see what HTTP status code it actually returns. This single step resolves about 70% of Azure Traffic Manager not working cases I've dealt with.
Open PowerShell and run this command against your endpoint's probe URL (replace the URL with your actual probe path):
Invoke-WebRequest 'http://your-endpoint.cloudapp.net/Probe' -MaximumRedirection 0 -ErrorAction SilentlyContinue | Select-Object StatusCode, StatusDescriptionThe -MaximumRedirection 0 flag is the key part, it stops PowerShell from automatically following any redirects, so you see the raw status code that Traffic Manager's probe system would see. If your output shows anything other than 200 OK, that's your problem right there.
If you see a 301 Moved Permanently or 302 Found, your web server is redirecting the probe request, maybe from HTTP to HTTPS, or from a bare domain to a www subdomain. Traffic Manager treats these redirects as failures unless you explicitly tell it they're acceptable. It does not follow the redirect and check the final destination.
The fix in that case is one of two things: either reconfigure your web server so the probe path returns a direct 200 without redirecting, or add the redirect status code (301, 302, etc.) to the Expected Status Code Ranges field in your Traffic Manager profile settings. You'll find this in the Azure portal under your Traffic Manager profile → Configuration → Expected status code ranges.
If you're running HTTPS probes and getting certificate-related errors during your PowerShell test, temporarily disable certificate validation for the test session to isolate the issue:
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicyNote: Traffic Manager's own HTTPS probes actually ignore certificate errors by design, so SSL/TLS issues won't cause probe failures in production, but this lets you cleanly test from your workstation without noise in the results.
/favicon.ico return 200 reliably but only confirm your web server process is alive, not that your app is actually healthy. Create a dedicated /health or /Probe.aspx endpoint that checks your database connection, cache availability, and at least one critical downstream dependency. If any of those fail, return a 503. This way Traffic Manager's probe actually reflects the real health of your application.
The single most important thing you can do when Azure Traffic Manager is not working is turn on resource logging. Without it, you're flying blind. Microsoft's official guidance is clear on this: enabling logging is the mandatory first step for any Traffic Manager degraded status investigation.
In the Azure portal, navigate to your Traffic Manager profile. In the left sidebar, find Monitoring → Diagnostic settings. Click Add diagnostic setting. Give it a name like tm-debug-logs. Under Logs, check ProbeHealthStatusEvents. Under Destination details, send the logs to a Log Analytics workspace, this gives you the most useful query interface.
Once logs are flowing (give it 5–10 minutes), go to your Log Analytics workspace and run this query:
AzureDiagnostics
| where ResourceType == "TRAFFICMANAGERPROFILES"
| where Category == "ProbeHealthStatusEvents"
| order by TimeGenerated desc
| take 50The results will show you exactly which endpoints are being probed, what response codes they're returning, and the timestamp of each probe. This is far more informative than the portal's status badges. You're looking for non-200 status codes in the httpStatusCode_d column, those are your failures.
If you see the probe isn't hitting your endpoint at all, check that the endpoint's DNS name resolves correctly from Azure's perspective. Traffic Manager probes originate from Azure infrastructure, not from your client network. A misconfigured DNS entry that resolves fine on your corporate network might not resolve from Azure's probing infrastructure.
When logging is working correctly, you'll see a continuous stream of probe events every 30 seconds (the default probe interval). If you see gaps, it could indicate a probe interval misconfiguration or a temporary Azure infrastructure issue.
This is where most Traffic Manager endpoint health check failures live. The probe path is the specific URL path Traffic Manager hits on your endpoint, and the default configuration is almost never appropriate for production workloads.
In the Azure portal, go to your Traffic Manager profile → Configuration. Look at the Endpoint monitoring settings section. You'll see fields for Protocol, Port, Path, and Expected status code ranges.
The default probe path is typically /, your homepage. Here's why that's a problem: your homepage might redirect to a localized URL, might trigger authentication, or might do a database query that times out under load. Any of those behaviors can cause probe failures even when your app is fundamentally healthy.
Change the probe path to a dedicated health endpoint. If you're running ASP.NET, create a /Probe.aspx or /health route that does the following and returns 200 only when everything checks out:
// Example lightweight health check endpoint response
// Return HTTP 200 only when DB and critical services are reachable
Response.StatusCode = 200;
Response.Write("OK");
Response.End();If you're running a service where a redirect is genuinely unavoidable from the probe path, go to the Expected status code ranges field and add the redirect code. The format is a range, for a single code like 301, enter 301-301. For a range covering 200 through 299 plus 301, add two entries: 200-299 and 301-301.
After saving the configuration change, Traffic Manager will start probing the new path immediately. Watch your diagnostic logs, within 2–3 probe cycles (roughly 1–2 minutes at default intervals) you should see the endpoint status shift from Degraded to Online. If it doesn't, move to the next step.
PowerShell's Invoke-WebRequest is convenient, but sometimes you need to see the full raw HTTP exchange to understand what's happening. This is where curl or Fiddler earns its place in the Azure Traffic Manager troubleshooting toolkit.
If you have curl available (it ships natively on Windows 10/11), run this against your probe URL:
curl -v --max-redirs 0 http://your-endpoint.cloudapp.net/ProbeThe -v flag shows verbose output including all request and response headers. The --max-redirs 0 stops curl from following redirects, just like Traffic Manager's probe behavior. Look at the first line of the response, that's your HTTP status code.
For HTTPS endpoints, add -k to skip certificate validation during your test (remember, Traffic Manager already ignores certificate errors on HTTPS probes natively):
curl -v -k --max-redirs 0 https://your-endpoint.cloudapp.net/ProbeIf you prefer a GUI, open Fiddler and manually browse to your probe URL. In the right panel, click the Raw tab in the response section. You'll see the exact HTTP response headers and status line that Traffic Manager's probe engine would receive.
Alternatively, in any modern browser, press F12 to open DevTools, go to the Network tab, disable the cache (check "Disable cache"), then navigate to your probe URL. Click on the request in the Network tab and look at the Headers → Status Code field. Note: browsers do follow redirects automatically, so look at the first request in the chain, not the final one.
Document the exact status code you see. If it's 200, Traffic Manager should be happy, if it's still showing Degraded, jump to the Advanced Troubleshooting section because there's something deeper going on. If it's anything else, you now have your confirmed root cause.
Sometimes Azure Traffic Manager endpoint offline status persists even after you've fixed the underlying probe problem. The portal's status display can lag behind reality by a few probe cycles. Here's how to get a current, accurate picture and force a re-evaluation.
In the Azure portal, navigate to your Traffic Manager profile → Endpoints. You'll see a table listing each endpoint with its current status (Online, Degraded, Disabled, Inactive). If an endpoint shows Disabled, that's not a probe failure, someone manually disabled it or the endpoint's parent resource was disabled. Click on the endpoint and toggle it back to Enabled.
To check endpoint health via PowerShell with more detail than the portal shows:
Get-AzTrafficManagerEndpoint -Name "your-endpoint-name" `
-ProfileName "your-profile-name" `
-ResourceGroupName "your-rg-name" `
-Type AzureEndpoints | Select-Object Name, EndpointStatus, EndpointMonitorStatusThe EndpointMonitorStatus field is more granular than what the portal shows. Values you might see:
Online - Probe returning 200, endpoint receiving traffic
Degraded - Probe failures detected
Disabled - Manually disabled
Inactive - Profile is disabled
CheckingEndpoint - Probe in progress, initial evaluation
Stopped - Endpoint's Azure service is stoppedIf the status is Stopped, it means the Azure resource the endpoint points to (a Cloud Service, App Service, etc.) is actually stopped or deallocated. Traffic Manager can't probe what doesn't exist. Go to that resource and start it.
After fixing the underlying issue, you don't need to do anything special to trigger re-evaluation, Traffic Manager probes continuously. But if you want a fresh status reading right now, use the Azure CLI:
az network traffic-manager endpoint show \
--name your-endpoint-name \
--profile-name your-profile-name \
--resource-group your-rg \
--type azureEndpoints \
--query "properties.endpointMonitorStatus"Keep refreshing every 30–60 seconds. Once it flips to Online, Traffic Manager will resume sending traffic to that endpoint based on your configured routing method.
If your endpoints are all showing as Online but traffic still isn't routing the way you expect, the issue is almost certainly in your routing method configuration. This is the second most common Azure Traffic Manager not working scenario, and it's entirely different from probe failures.
Azure Traffic Manager supports several routing methods, and picking the wrong one, or misconfiguring the right one, causes exactly the kind of "everything looks fine but traffic goes to the wrong place" symptoms that are maddening to debug.
In the Azure portal, go to your Traffic Manager profile → Configuration → Routing method. The options are:
Priority - Route all traffic to the primary endpoint; failover to secondary
Weighted - Distribute traffic by assigned weight percentages
Performance - Route to endpoint with lowest latency for the client
Geographic - Route based on the client's geographic region
Multivalue - Return multiple healthy endpoints (DNS-based)
Subnet - Route based on client IP address rangesFor Priority routing: check the priority numbers assigned to each endpoint. Lower numbers = higher priority. If your primary endpoint has priority 2 and your failover has priority 1, traffic will always go to the failover endpoint, the opposite of what you intended. Fix the numbers so your primary endpoint has priority 1.
For Weighted routing: verify the weight values add up and are distributed correctly. An endpoint with weight 0 receives no traffic. If all your weights are equal, Traffic Manager distributes evenly. Adjust weights in the endpoint configuration panel.
For Geographic routing: every client request must match a geographic mapping. If a region isn't mapped to any endpoint, those clients won't reach your service at all. Make sure you have a World (All) mapping set as a catch-all on at least one endpoint unless you intentionally want to block unmapped regions.
After changing the routing method, save the configuration and wait 1–2 minutes for the DNS TTL to propagate. Test from a client in the expected region using nslookup your-profile.trafficmanager.net to confirm which endpoint DNS is resolving to.
Advanced Troubleshooting for Azure Traffic Manager
If you've worked through all five steps above and Azure Traffic Manager is still not working correctly, you're dealing with something at a deeper layer. Here's where to go next.
DNS Resolution and TTL Issues
Traffic Manager works entirely through DNS, it doesn't sit in the data path of your traffic. This means DNS caching can make problems look like they've been fixed (or make fixes look like they haven't taken effect) for a confusing amount of time. Check the TTL on your Traffic Manager profile's DNS responses:
Resolve-DnsName your-profile.trafficmanager.net -Type CNAME | Select-Object Name, TTL, NameHostThe default TTL for Traffic Manager DNS responses is 60 seconds. If your clients have cached a stale DNS response pointing to a Degraded endpoint, they'll keep hitting it until the TTL expires. During an incident, you can temporarily lower the TTL in your profile settings to speed up propagation, go to your profile → Configuration → DNS time to live (TTL).
Nested Profile Issues
If you're using nested Traffic Manager profiles (a parent profile with child profiles as endpoints), the health status calculation works differently. A child profile is considered healthy only if at least a minimum number of its own endpoints are healthy, this threshold is configurable. If you've set the minimum threshold too high, the parent might mark the child profile as Degraded even when it has some healthy endpoints. Check this under the child endpoint configuration in the parent profile: look for the Minimum child endpoints setting.
Network Security Groups and Firewall Rules
Traffic Manager probes originate from Azure's infrastructure. If you have Network Security Groups (NSGs) or firewall rules on your endpoints that block inbound traffic from Azure IP ranges, probes will fail silently. The endpoint will show as Degraded, but your app is perfectly fine for real user traffic coming from other sources.
Check your NSG inbound rules. Traffic Manager probes come from the AzureTrafficManager service tag. Add an inbound allow rule for this service tag on the probe port (typically 80 or 443):
az network nsg rule create \
--resource-group your-rg \
--nsg-name your-nsg \
--name AllowTrafficManagerProbes \
--priority 200 \
--source-address-prefixes AzureTrafficManager \
--destination-port-ranges 80 443 \
--access Allow \
--protocol TcpApp Service Custom Domain and SSL Binding Conflicts
If your endpoint is an Azure App Service with a custom domain and you're probing via the .azurewebsites.net address, the probe might be landing on the default page rather than your application. Confirm the probe hostname matches what your application expects in the Host header, some apps reject requests with unexpected hostnames at the application layer before they even generate a response.
Reading Event Logs and Activity Logs
In the Azure portal, go to your Traffic Manager profile → Activity log. Filter by the last 24–48 hours. Look for any Update Traffic Manager profile or Delete endpoint events, these tell you if someone changed configuration recently and when. If a configuration change correlates with when your problems started, that's your smoking gun.
If your probe URL returns HTTP 200, your NSG rules allow Traffic Manager probes, your routing method is correctly configured, and your endpoints still show Degraded in the portal, you're likely hitting a platform-side issue or a bug in Traffic Manager's probe infrastructure for your specific region. At that point, open a support ticket with Azure. Document your diagnostic log output, the exact PowerShell probe test results, and a timeline of when the issue started. Having this ready cuts the support resolution time significantly. You can reach Microsoft Support directly through the Azure portal under Help + support → New support request.
Prevention & Best Practices for Azure Traffic Manager
I'd rather help you never see a Degraded status badge again than keep troubleshooting the same issue. Here's what the teams I've worked with do that separates stable Traffic Manager deployments from the ones that page someone at 2am.
Build a Real Health Endpoint, Not a Fake One
This is the single most impactful change you can make. Your probe path should hit an endpoint that actively validates your application's health. A good health check for a web app checks at minimum: database connectivity (a lightweight query like SELECT 1), cache availability if your app depends on it, and any critical third-party API your service depends on. If any check fails, return 503. If everything passes, return 200. This turns Traffic Manager into a genuine health-aware load balancer instead of a DNS alias with extra steps.
Set Alerts on Traffic Manager Status Changes
Don't find out about Degraded status from a user complaint. In the Azure portal, go to your Traffic Manager profile → Alerts → New alert rule. Create an alert on the metric Endpoint Status by Endpoint, condition Less than 1, for each critical endpoint. Route the alert to an action group that sends email or fires a webhook to your on-call system. You'll know within 2 minutes of an endpoint going offline.
Document Your Expected Status Code Ranges Up Front
Before deploying a new Traffic Manager profile to production, spend 10 minutes documenting what HTTP response codes your probe endpoint returns in every scenario: healthy, database down, cache miss, maintenance mode. Then configure Expected status code ranges in the Traffic Manager profile to match exactly what you intend. Don't assume 200 is the only code your app ever returns from the probe path, maintenance pages often return 503, which is actually the correct behavior you want Traffic Manager to treat as a failure.
Test Failover Before You Need It
Manually disable your primary endpoint in the portal and verify that traffic actually shifts to your secondary within the expected time window. Do this in a maintenance window before you're ever in an actual incident. The number of teams who have failover configured but have never tested it, and discover it doesn't work during an actual outage, is genuinely alarming. Run this test quarterly.
- Set the probe interval to 10 seconds (Fast probing) for production profiles, the default 30 seconds means a full minute can pass before failover starts
- Add the
AzureTrafficManagerservice tag as an inbound allow rule on every endpoint's NSG before you deploy, don't wait until probes start failing - Use a probe port that matches your application's actual port, a probe on port 80 that returns 200 means nothing if your real users hit port 443 and get a certificate error
- Review your Traffic Manager profile's Activity Log after any infrastructure change, even unrelated Azure resource changes can affect endpoint reachability
Frequently Asked Questions
Why does my Traffic Manager show Degraded even though my website loads fine in the browser?
This is the most common source of confusion. Your browser automatically follows HTTP redirects, so if your site returns a 301 from the probe path, your browser happily follows it to the final destination and loads the page. Traffic Manager's probe doesn't follow redirects. It sees the 301 and immediately marks the endpoint as offline. The fix is either to make the probe path return 200 directly, or add 301 to your profile's Expected status code ranges. Your site isn't broken, Traffic Manager just doesn't like how it's responding to that specific probe URL.
What happens if ALL my Traffic Manager endpoints go degraded at the same time?
Azure Traffic Manager has a safety behavior specifically for this scenario: when every endpoint in a profile degrades simultaneously, Traffic Manager ignores the degraded status and routes traffic to all of them anyway. This prevents a situation where a broken probe mechanism causes a total service outage. It's not ideal, you'd want to know about it and fix it, but your users won't see a complete outage. Set up alerting so you know when this happens, because it means either all your endpoints are genuinely failing or your probing setup has a systematic problem that needs attention.
How long does it take for Traffic Manager to detect a failed endpoint and reroute traffic?
The failover time depends on three settings working together: probe interval, tolerated number of failures, and DNS TTL. With default settings (30-second probe interval, 3 tolerated failures, 60-second TTL), worst-case failover is about 3.5 minutes, three failed probes take up to 90 seconds, then DNS TTL adds another 60 seconds, plus client-side DNS cache. If you switch to Fast probing (10-second interval) and lower the TTL to 30 seconds, you can get that down to under a minute. The tradeoff is slightly higher probe traffic and more sensitivity to transient blips.
Does Traffic Manager work with Azure App Service, or only with Cloud Services and VMs?
Traffic Manager works with Azure App Service, Cloud Services, VMs with public IPs, external endpoints (any internet-facing URL), and nested Traffic Manager profiles. For App Services, you add them as Azure Endpoints, Traffic Manager uses the App Service's built-in .azurewebsites.net address for probing. One thing to watch: if your App Service has IP restrictions configured, make sure the AzureTrafficManager service tag is in the allowed list, or probes will fail silently from the app's perspective while looking like a 403 or timeout to Traffic Manager.
Can Traffic Manager route traffic based on the path in the URL, like /api vs /app?
No, and this is a common misconception that leads to architectural headaches. Traffic Manager operates entirely at the DNS level and routes based on who is making the request (their geography, latency, etc.), not what URL path they're requesting. It can't inspect the HTTP path. If you need path-based routing (/api goes to one backend, /app goes to another), you want Azure Application Gateway or Azure Front Door, which operate at Layer 7 and can make routing decisions based on URL paths, headers, and more. Traffic Manager and Front Door are often used together, Traffic Manager for DNS-level global routing, Front Door for intelligent path-based routing within a region.
My Traffic Manager probe is HTTPS but my certificate is self-signed, will that cause probe failures?
No, this is one of the few things Traffic Manager handles gracefully out of the box. HTTPS probes in Traffic Manager explicitly ignore certificate errors, including self-signed certificates, expired certificates, and hostname mismatches. So a self-signed cert on your endpoint won't cause the probe to fail. That said, your real users' browsers will absolutely reject self-signed certificates with scary warnings, so this should only be a temporary state during development or internal testing, not a permanent production configuration.