Front Door route/endpoint deploymentStatus stuck at NotStarted for 5+ hours, persists after full endpoint recreation

Question

Front Door route/endpoint deploymentStatus stuck at NotStarted for 5+ hours, persists after full endpoint recreation

Ravi Mamidala 0

Details:

Azure Front Door Standard profile "raar-dev-afd" (resource group "raar-dev-rg") is not routing any traffic to its origin. Every request to the custom domain returns HTTP 504.

Symptom: az afd route show and az afd endpoint show both report provisioningState: "Succeeded" but deploymentStatus: "NotStarted" — stuck indefinitely, first observed today and unresolved for over 5 hours.

Latest RefString: 20260815T195552Z-r15f8ccd5fbmr9p9hC1IADwagw0000000h3000000000bbvy

Resource IDs:

Subscription: 36a23df3-a484-420b-afc9-9aa1828db8ca
Resource group: raar-dev-rg
Profile: raar-dev-afd
Endpoint: raar-dev-endpoint
Route: raar-dev-route
Custom domain: dev.raarventures.com

What's been ruled out:

DNS: confirmed correct at the authoritative .com registry level directly (not just cached resolvers) — raarventures.com correctly delegates to the four Azure DNS nameservers with a fresh 48-hour TTL glue record. The origin's own hostname (an AKS ingress-nginx LoadBalancer) also resolves correctly to its current IP. Verified independently across 4 public resolvers (Google, Cloudflare, Quad9, OpenDNS) plus the TLD registry itself.
Certificate: the origin serves a real, valid, publicly-trusted Let's Encrypt production certificate for the correct hostname (not self-signed). Front Door's managed certificate for the custom domain also shows domainValidationState: Approved and deploymentStatus: Succeeded on its own.
Origin connectivity: origin-side logs (ingress-nginx access/error logs on the AKS backend) show zero incoming connection attempts from Front Door at any point. This is not a real origin timeout — Front Door's edge is never even attempting to reach the origin.

What's been tried (none resolved it):

Waiting (multiple hours, monitored continuously)
Deleting and recreating the route (terraform apply -replace)
No-op updates to the route and endpoint to nudge the deployment pipeline
az afd endpoint purge (cache purge)
Deleting and fully recreating the endpoint itself (a completely fresh resource, new creation timestamp) — the identical NotStarted symptom recurred immediately on the new resource, which points away from anything specific to the original resource's state/history and toward a platform-level condition.

This looks like a stuck Front Door control-plane deployment pipeline (config not propagating to the edge network), not a configuration error on our end.

Can someone help from Microsoft support . Getting to support is little pathetic here

0 comments

2 answers

Your answer

Answer 1

Allan Solomon Mejia 7,915

Hello @Ravi Mamidala

Based on the details provided, I would not treat deploymentStatus: NotStarted alone as proof that the Front Door edge configuration failed to deploy. Microsoft has previously clarified that NotStarted can be a cosmetic/status-reporting condition when provisioningState is Succeeded.

However, the HTTP 504 combined with zero requests reaching the AKS origin still needs investigation.

Since you have already recreated the endpoint/route and validated DNS, TLS, and direct origin accessibility, I suggest checking the Front Door diagnostic logs, particularly FrontDoorAccessLog and FrontDoorHealthProbeLog, and correlate them using the X-Azure-Ref/RefString from the failed request. This should establish whether Front Door selected the route and origin and why the request did not reach the backend.

A very similar case had provisioningState: Succeeded, deploymentStatus: NotStarted, and gateway errors, but Microsoft ultimately needed the diagnostic data to determine what was happening in the Front Door request path.

Given that this has persisted for 5+ hours and survives complete endpoint recreation, I would also open an Azure Front Door support request and provide the profile/endpoint/route resource IDs, UTC timestamps, RefString, and relevant diagnostic logs. Microsoft support can inspect the backend/edge telemetry that isn't exposed through the portal or CLI.

I would avoid repeatedly deleting/recreating the resources at this stage, since you already have a clean reproduction that will be more useful for support investigation.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Ravi Mamidala 0 Reputation points

2026-08-15T23:37:33.8133333+00:00

Hi Allan .. Thanks for the response .. Support ticket is exactly iam unable to do . I don't find that link in my azure portal at all .. all I see is AI and it is of no issue . I do have support subscription
Allan Solomon Mejia 7,915 Reputation points

2026-08-15T23:54:48.38+00:00

Hi @Ravi Mamidala

Thanks for clarifying. Since you already have an Azure support subscription, you should be able to create a technical support request. The Azure portal interface has changed, so the option may be hidden behind the newer Help + support / Support + Troubleshooting experience.

Try going directly to: Create an Azure support request | https://azure.microsoft.com/en-us/support/create-ticket

Alternatively, from the Azure portal, select the ? (Help) icon in the top bar, describe the Front Door issue, go through the suggested troubleshooting, and then select Create a support request. From the Front Door resource itself, you can also look under Help > Support + Troubleshooting.

Since you mentioned you're only seeing the AI assistance, make sure you continue through the troubleshooting prompts rather than stopping at the suggested solutions. The Create a support request option should appear if the issue remains unresolved.

Also verify that your account has Owner, Contributor, or Support Request Contributor at the subscription level. Having a paid support plan alone isn't enough if the signed-in account doesn't have the required Microsoft.Support/* permissions.

For this case, select Technical and choose Azure Front Door/CDN as the service, then provide the RefString, UTC timestamp, profile/endpoint/route resource IDs, and mention that the issue persists after complete endpoint recreation.

If the direct link still doesn't allow you to create the request despite the support plan and correct RBAC permissions, let us know what screen/message you get. That would indicate the support-request access itself needs to be investigated.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.
Ravi Mamidala 0 Reputation points

2026-08-16T02:12:48.28+00:00
Root cause chain, full session

Azure Standard LB health probe used path / → ingress-nginx returned 404 (no matching route) → Azure marked the backend unhealthy → Front Door got zero healthy origins → 504 for everyone. Fixed via the azure-load-balancer-health-probe-request-path: /healthz Service annotation.

That exposed a second, previously-hidden issue: Front Door's TLS handshake to the origin uses the origin's raw hostname as SNI, which didn't match any configured Ingress TLS host, so nginx served its self-signed default cert → 502 OriginCertificateSelfSigned. Fixed by setting nginx's default TLS certificate to the already-issued Let's Encrypt cert via helm upgrade (controller.extraArgs.default-ssl-certificate).

That exposed a third issue: the served cert's CN didn't match the origin's raw hostname (expected, since we can't get a public cert for Microsoft's own *.cloudapp.azure.com domain) → 502 CertificateNameCheckFailed. Fixed by disabling enforceCertificateNameCheck on both Front Door origins.

The dashboard route picked up that last change within ~10 minutes; the API route took roughly 90 minutes longer to propagate to the edge, despite identical config throughout — confirmed now resolved on its own.

No Front Door or AKS resources were recreated; the dashboard path was never touched during the API-specific investigation.
Allan Solomon Mejia 7,915 Reputation points

2026-08-16T16:18:12.2866667+00:00

Hi @Ravi Mamidala

Please let me know if you need any further assistance. Otherwise, if the information provided has resolved your issue, please consider clicking “Accept Answer” to help others who may encounter the same problem.

Thank you!

Answer 2

Here is additional diagnostics

Azure Standard Public IP unreachable from the internet but reachable from inside the same VNet — causing Front Door 504s (AKS Standard LB origin)

Environment

Front Door Standard profile: raar-dev-afd (resource group raar-dev-rg), endpoint raar-dev-endpoint-aqaef0bjd3aagzbx.z03.azurefd.net, provisioningState: Succeeded.
Custom domains: dev.raarventures.com, api.dev.raarventures.com (both routes enabledState: Enabled, provisioningState: Succeeded).
Origin groups: raar-dev-origin-group / raar-dev-api-origin-group, each with a single origin pointing at raar-dev-ingress.eastus.cloudapp.azure.com → public IP 172.171.83.113, health probe HTTPS GET on /legal/terms and /health/ready respectively, 30s interval.
Origin is an AKS (raar-dev-aks, K8s 1.35.6) ingress-nginx controller Service of type LoadBalancer, backed by the standard AKS-managed Azure Standard Load Balancer (kubernetes LB in MC_raar-dev-rg_raar-dev-aks_eastus), Standard SKU public IP, zone-redundant (zones 1,2,3), ddosSettings.protectionMode: VirtualNetworkInherited.

Symptom

Every client request to both custom domains returns HTTP/2 504 directly from the Front Door edge (content-type: text/html, content-length: 2061, cache-control: no-store, x-cache: CONFIG_NOCACHE — Front Door's own generic 504 page, not a proxied response from origin).

TrackingReferences for support to pull

20260815T232753Z-1769666fcd6f2hqdhC1PHLkbac000000087g000000003rgf (dev.raarventures.com, 2026-08-15T23:27:53Z)
20260815T232801Z-1769666fcd66d76rhC1PHLkrbc000000076g00000000c8u5 (api.dev.raarventures.com, 2026-08-15T23:28:01Z)
20260815T233340Z-r15f8ccd5fb8rxq6hC1IADvp6n00000035ag000000005g3c (dev.raarventures.com, 2026-08-15T23:33:40Z)
20260815T233348Z-r15f8ccd5fbqg54shC1IADps8000000035800000000038v8 (api.dev.raarventures.com, 2026-08-15T23:33:48Z)
20260815T235446Z-17b47974d968p7sdhC1BL1rqw400000003u0000000001kx6 (dev.raarventures.com, 2026-08-15T23:54:46Z)
20260815T235455Z-17b47974d966sz7fhC1BL1mgwc000000046g000000003dyb (api.dev.raarventures.com, 2026-08-15T23:54:55Z)

⭐ Decisive finding: internal-good / external-bad on the same VIP

From a pod inside the AKS cluster's own VNet, hitting the public LB frontend IP directly returns a clean success:

curl -H "Host: dev.raarventures.com" https://172.171.83.113/legal/terms → HTTP 200

Both backend NodePorts (30575 HTTP, 32764 HTTPS) also respond correctly from inside the cluster, on both nodes.

From outside — my own machine, and Front Door's global edge network — the exact same IP times out completely:

curl -H "Host: dev.raarventures.com" https://172.171.83.113/legal/terms → connection timeout

This proves the backend, Service, Endpoints, kube-proxy, and LB backend pool are all healthy and correctly configured — the failure is isolated to the internet-to-VIP path specifically, not to anything in our Kubernetes or LB configuration.

Supporting metrics (Azure Monitor, sampled over ~1 hour)

Front Door raar-dev-afd: RequestCount nonzero (client traffic reaching the edge, 7–27 req/min), OriginHealthPercentage = 0.0% every interval, OriginRequestCount = 0 (Front Door never forwards to origin), Percentage5XX 60–100%+, WebApplicationFirewallRequestCount tracks RequestCount ~1:1 (WAF evaluating normally, not blocking).
AKS-managed Load Balancer (kubernetes, RG MC_raar-dev-rg_raar-dev-aks_eastus): VipAvailability = 0.0%, DipAvailability = 0.0% for the full window — Azure's own external synthetic monitoring, consistent with the external-unreachability finding above.

What we've ruled out ourselves

DNS resolves correctly.
ingress-nginx-controller pod 1/1 Running; Service has valid Endpoints.
kube-proxy healthy on both nodes, iptables rules synced with no errors.
No Kubernetes NetworkPolicy restricting the ingress-nginx namespace.
No VMSS Application Health Extension in play (not installed on this node pool).
LB rules/health-probe settings/backend pool correctly reference both VMSS NodePorts and both instance NICs, all provisioningState: Succeeded.
Custom NSG rule explicitly allows Internet → 172.171.83.113:80,443.
Public IP SKU (Standard) matches LB SKU (Standard) — no SKU mismatch.
WAF evaluating traffic normally, not blocking (response isn't a WAF block page).
deploymentStatus: NotStarted on the Front Door endpoint/routes/origin groups — per prior guidance this is believed cosmetic when provisioningState: Succeeded; not treated as root cause here.

What we could not do ourselves

Network Watcher IP Flow Verify against the actual LB health-probe source — Azure rejects 168.63.129.16 as a "restricted/virtualized address," so we can't directly simulate/verify the probe path via that tool.
Diagnostic logs still not flowing — a diagnostic setting was added on raar-dev-afd (FrontDoorAccessLog/FrontDoorHealthProbeLog/FrontDoorWebApplicationFirewallLog → Log Analytics, logAnalyticsDestinationType: Dedicated). 30+ minutes later, none of the three resource-specific tables have even been created in the workspace. Is this expected, or is something blocking first-time table provisioning?
We have only one external vantage point confirming the timeout (our own network) — corroborated by Front Door's globally-distributed health probes also failing uniformly, which suggests it isn't a local/single-path issue, but we can't independently verify from a second unrelated network ourselves as conclusively as Microsoft's internal tooling could.

Core question

A Standard Public IP (172.171.83.113, zone-redundant, provisioningState: Succeeded) backing a Standard Load Balancer is reachable and returns correct responses from inside its own VNet, but times out for all internet-sourced traffic, including Azure Front Door's own globally-distributed health probes. NSG, backend health, Service/Endpoints, and kube-proxy are all confirmed correct. What would cause a Standard Public IP to stop accepting internet-sourced traffic while remaining reachable intra-VNet, and how can we get visibility into whether this is an edge-route/BGP-advertisement issue on Microsoft's side for this specific IP?

Ravi Mamidala 0 Reputation points

2026-08-16T01:13:34.2833333+00:00

Update: attempted self-service fix, no effect

We disassociated the LB frontend's public IP (172.171.83.113), attached a temporary placeholder IP, confirmed it reachable internally, then reassociated the original public IP. provisioningState: Succeeded throughout. External reachability to 172.171.83.113 remained identical after this — still complete connection timeout — while internal VNet access to the same IP continued to return HTTP 200 immediately, before and after. This rules out a stale/stuck provisioning state as the cause; re-provisioning the same IP onto the frontend did not change its internet-facing behavior at all.