Azure Front Door continues health probing an unassociated Origin Group

Question

Hi,

I'm using Azure Front Door Standard/Premium. My DR Origin Group was removed from all routes on Friday and now shows Unassociated in the portal. The only active route is associated with the Production Origin Group.

However, today I received an OriginHealthPercentage alert (Value = 0, Threshold < 100). Looking at the FrontDoorHealthProbeLog, I found that Front Door was still sending health probes to the DR App Service, even though its Origin Group is unassociated.

The probe log shows:

• result_s = OriginError
• httpStatusCode_s = 0
• connectionLatencyMilliseconds = 105
• totalLatencyMilliseconds = 4423

At the same time:

• No deployments were performed.
• No App Service restart/recycle occurred (Prod or DR).
• No HTTP 5xx errors were observed.
• The active Production Origin Group remained healthy.

My questions are:

1. Is it expected that Front Door continues sending health probes to an unassociated Origin Group?
2. Does the OriginHealthPercentage metric include unassociated Origin Groups, allowing them to trigger profile-level alerts?
3. Or should health probes stop once an Origin Group is no longer associated with any route?

Any clarification or documentation on this behavior would be appreciated.

Answer 1

Hi @Sanjay kumar

Based on the documented behavior, Azure Front Door health probes are associated with origin groups, and Front Door periodically probes the origins configured within those groups to determine health and latency. The documentation doesn't explicitly state whether probes stop immediately when an origin group becomes unassociated (no longer referenced by any route).

Since your origin group is still present (rather than deleted or its origins being disabled), it's possible that Front Door continues probing it until the configuration has fully propagated or because the origin group remains a managed resource within the profile. However, I wouldn't expect it to continue indefinitely if no route references it.

A couple of things I'd verify:

• Confirm there are no remaining routes, rule sets, or endpoints referencing the DR origin group (including disabled or recently modified routes).
• Check whether the origin itself is still enabled. Microsoft documents that disabling an origin stops both routing and health probes to that origin.
• If the behavior persists well beyond the normal configuration propagation window, it may indicate a platform issue. Collect the FrontDoorHealthProbeLog, Front Door resource ID, and the approximate timestamps, then open a Microsoft support case so engineering can verify whether the profile is still scheduling probes for that origin group.

I'd also be interested in whether the OriginHealthPercentage metric is expected to include unassociated origin groups. I couldn't find documentation confirming that behavior, so clarification from the Azure Front Door engineering team would be valuable.

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