Front door provisioning state failed after putting a Traffic Manager between DNS server and front door

To give some more insights. Health probe are responding well on TM and FD.

Hi Salguero Herrero, Humberto,

Welcome to Microsoft Q&A and thank you for posting your query here!

This behavior usually happens because Azure Front Door can’t successfully validate or reach its origin when a Traffic Manager profile is placed in front of it. Even though your application works and probes look healthy, the Front Door provisioning logic performs its own internal validation against the configured origin hostname — and this validation can fail when a Traffic Manager sits between them.

Here are the main causes and steps to verify:

1. Origin hostname validation

During provisioning, Front Door needs to verify that the origin hostname you’ve configured is publicly resolvable and reachable. If your Front Door origin points to a Traffic Manager DNS name (e.g., myapp.trafficmanager.net), Front Door’s internal validation may fail because:

• Traffic Manager might resolve to different backends dynamically.
• Front Door can’t confirm the target endpoint’s certificate or expected IP address.

Try changing the origin in Front Door to point directly to the underlying endpoint (for example, the Public IP or Load Balancer FQDN) instead of the Traffic Manager name — at least for validation. Once provisioning succeeds, you can optionally test routing through TM again.

2. HTTPS certificate mismatch

If your origin uses HTTPS and the hostname configured in Front Door doesn’t match the certificate on the origin (for example, if the TM profile name differs from the origin’s CN/SAN), Front Door’s validation will fail.

So, Ensure the TLS certificate on your backend covers the exact hostname that Front Door uses to reach it, or configure a custom origin host header in Front Door to match the certificate’s CN.

3. Health probe configuration

Even though TM and FD probes are responding, the Front Door provisioning process also runs internal health checks. If these checks return unexpected results (e.g., 301/302 redirects or non-200 responses), the provisioning state can be set to Failed even though live traffic continues to flow.

So, verify that the origin health probe in Front Door returns HTTP 200 OK with no redirects.

4. Known limitation

Microsoft generally recommends not chaining Front Door and Traffic Manager for the same endpoint unless there’s a specific global failover use case. Front Door already provides global load balancing and health probing natively, so putting TM in front of it can cause provisioning and validation issues like this.

Reference:

1. Azure Front Door – Origin configuration and validation
2. Azure Traffic Manager and Front Door best practices

i hope the above response will help you out, please do let me know if you have any questions on this.

if this response helps clarify your query, kindly consider accepting the answer so others can benefit as well.

Thanks,

Harish.

Dear Harish,

Thank you very much for your promt feedback.

Just one clarification. Our current incoming routing configuration would be:

     DNS  --> Traffic Manager --> Front Door --> Load balancer

This is the configuration that is provoking (as far as we could understand) the provisioning failure status.

As I could understand from your response, you were basing your explanation in this configuration

     DNS --> Front Door --> Traffic Manager --> Load Balancer

Is this right? Would the origin provisioning status be "Failed" in both configuration options?

Anyway your last paragraph is quite clear, Azure generally does not recommend chaning Front Door and Traffic manager.

Thank you again

Br

Humberto