AFD health probe failures- DNS failures and Connection timeouts seen in logs

Question

AFD health probe failures- DNS failures and Connection timeouts seen in logs

Maitree Leekha 5 Microsoft Employee

Our AFD health probes started experiencing drops, and specifically DNS or connection failures. This started happening when we made a small change to disable a region in the AFD. After which, all the origin group and all the origins within started experiencing small reliability drops randomly. None of the apps corresponding to these origins were re-deployed during the time, nor did anything else change w.r.t them.

Mythreya Asnala 0 Reputation points Microsoft External Staff Moderator

2026-08-03T10:30:42.6833333+00:00
Hi @Maitree Leekha ,

It appears that the health probes from the remaining edge stopped working after you disabled one of your Front Door areas. PoPs are now occasionally experiencing TCP connection timeouts or DNS lookup problems against your origins. Disabling a region affects which PoPs submit probes and how fast your DNS or network paths respond, but it has no effect on your apps. Here are a few things to look at and try:

Inspect your health-probe logs

In Azure Monitor (or Front Door diagnostic logs), look at each failed entry’s “Result” (e.g. dnsFailure vs connectionTimeout), plus the DNSResolutionLatency and ConnectionLatency fields.

See if failures are coming from just one or two PoPs or are spread across all PoPs.

Validate your health-probe configuration

Protocol, method (GET vs HEAD), path.

Interval, SampleSize (n), SuccessfulSamplesRequired (x) and timeouts. If you now have slightly higher latency, your existing thresholds may be too tight.

Review your DNS setup

If your origin is specified as a FQDN, each edge PoP has to resolve it before probing. Disabling a region may have evicted cached records and triggered fresh lookups under load.

Ensure your DNS provider is responsive and highly available. Consider lowering your TTL or hosting in Azure DNS for faster resolution.

Consider your network paths

Some PoPs might now be routing over different backbones, introducing modest latency. If your probe timeout is small, those latencies can translate into connectionTimeout errors.

Tune or disable probes (for single-origin groups)

If you only have one origin in a group, you can disable health probes to avoid false drops. For multi-origin groups, you can increase your SampleSize or SuccessfulSamplesRequired so that a handful of probe hiccups don’t mark the origin unhealthy.

Could you please provide the answers for the below Follow-up questions to investigate further:

• Which region did you disable, and is your origin group multi-region or Single-Region?

• Are your origins defined by FQDN or by IP address?

• What are your current probe settings (protocol, method, interval, SampleSize, SuccessfulSamplesRequired)?

• In your logs, are the failures clustered to specific PoPs or evenly distributed?

• Did you notice a spike in DNSResolutionLatency or ConnectionLatency after the change?

Reference docs for more details:

• Configure health probes – how Front Door determines health, SampleSize/SamplesRequired, probe behavior: https://learn.microsoft.com/azure/frontdoor/front-door-health-probes
• Configure Azure Front Door Standard/Premium health probes – settings and best practices: https://learn.microsoft.com/azure/frontdoor/health-probes
• Monitor Azure Front Door (Standard/Premium) – health probe log schema and metrics: https://learn.microsoft.com/azure/frontdoor/monitor-front-door
• Complete health probe failure and disabling probes in single-origin groups: https://learn.microsoft.com/azure/frontdoor/health-probes?tabs=frontend-standard#complete-health-probe-failure

I hope this may help you find your way! We can delve deeper if you provide the answers to the follow-up questions.
Mythreya Asnala 0 Reputation points Microsoft External Staff Moderator

2026-08-24T05:52:17.83+00:00

Hi Maitree Lekha,

I wanted to follow up on our previous conversation and check if you had an opportunity to review the information shared. If you have any questions or concerns please feel free to let me know.

2 answers

Your answer

Mythreya Asnala 0 Reputation points Microsoft External Staff Moderator

2026-08-24T05:52:17.83+00:00

Hi Maitree Lekha,

I wanted to follow up on our previous conversation and check if you had an opportunity to review the information shared. If you have any questions or concerns please feel free to let me know.

Answer 1

Hello Maitree Leekha,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having AFD health probe failures- DNS failures and Connection timeouts seen in logs.

The issue is not caused by application deployment, but by origin reachability and resolution failures from Front Door edge locations, which must be diagnosed and corrected based on the exact probe failure type.

The resolution path will help you fix it:

Enable Front Door diagnostic logs and Activity Logs to determine the exact failure type (DNSFailure, DNSTimeout, or connection errors) and correlate with configuration changes
If DNS failures are present, ensure the origin FQDN is publicly resolvable and reachable, or migrate to Front Door Premium with Private Link if the origin is intended to be private
If connection failures occur, allow traffic from AzureFrontDoor.Backend and required Azure infrastructure IPs, and ensure the origin endpoint responds correctly
Validate that the health probe endpoint returns fast HTTP 200 responses on the configured protocol/port
Disable health probes for single-origin groups, as they do not affect routing and can introduce unnecessary probe failures

After implementing the correct origin access model (public vs Private Link), and once logs are enabled, failure type is isolated, DNS consistency is restored or Private Link is implemented, and origin access is properly configured, AFD health probes will stabilize and reliability drops will be eliminated across all edge locations.

The below links are for more reading and steps:

Azure Front Door Health Probes:
https://learn.microsoft.com/azure/frontdoor/health-probes

Azure Front Door Monitoring & Logs:
https://learn.microsoft.com/azure/frontdoor/standard-premium/how-to-logs

Secure Origin Access (Service Tags & IPs):
https://learn.microsoft.com/azure/frontdoor/origin-security

Private Link with Azure Front Door Premium:
https://learn.microsoft.com/azure/frontdoor/private-link

Origins and Reachability Requirements:
https://learn.microsoft.com/azure/frontdoor/origin

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Answer 2

Hi Maitree Leekha ,

Thank you for sharing the details. Based on the symptoms, this appears to be related to Azure Front Door health probe reachability (DNS resolution or connectivity) rather than an application issue.

Azure Front Door sends health probes from multiple global edge locations to all configured origins, and any failure to receive a valid response (including DNSFailure, DNSTimeout, or connection timeout) is treated as an unhealthy signal.

Since the issue started immediately after disabling a region and is impacting all origins with intermittent reliability drops, this is most likely due to DNS resolution inconsistencies or transient connectivity issues from certain edge locations, possibly triggered by the configuration change. Such issues can occur even when backend applications are healthy.

Could you please help confirm the following:

Are the origin hostnames (FQDNs) publicly resolvable consistently from different geographic regions?
Are you using Azure DNS or a third-party DNS provider? Any recent DNS changes or low TTL values?
Do the failures occur across all edge locations or only specific regions (based on FrontDoorHealthProbeLogs)?
Are there any firewall, NSG, or origin-level restrictions that could block requests from certain Front Door POPs?
Is the origin accessible over the configured protocol/port (HTTP/HTTPS) from external endpoints at all times?

You can validate DNS resolution from an Azure context using Cloud Shell:

nslookup <origin-FQDN>

This helps confirm whether the origin hostname is resolving correctly. Inconsistent or delayed resolution can contribute to DNSFailure/DNSTimeout errors observed in health probes.

Let me know the results!

Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator

2026-05-26T10:18:28.3366667+00:00

Hi Maitree Leekha ,

Kindly let us know if the above helps or you need further assistance on this issue.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".