Front Door: Unavailable (Unplanned) : Unavailable Backends (Unplanned)

Question

Front Door: Unavailable (Unplanned) : Unavailable Backends (Unplanned)

Davor Teskera 30

hi,

we are getting daily lots of these health events in Resource Health from our front door instance.

example:

At Friday, 10 July 2026 at 3:14:42 pm CEST, the Azure monitoring system received the following information regarding your Cdn profile: One or more of your Front Door/CDN profiles backends are responding with errors to health probes. The backends associated with this Front Door/CDN profile are not responding to health probes with the expected status. Recommended Steps

The detected Origin Health event represents an aggregate health status across all your origins. Please check 'Origin Health Percentage' metrics in Metrics blade (Monitoring section) to identify the specific origin that is experiencing issues.

Review 'Origin Health Percentage' metrics in metrics and logs documentation

Origin groups with single origin will cause higher false positive as health probes are not effective for single origins. Please follow best practices to disable health probes.

If you are experiencing problems you believe are caused by Azure, contact support .

Most of these appear to be false positives — the site works fine and metrics show no issue.

However, one event on 9 July 2026 correlated with a real, user-facing incident, which is the focus of this question:

What we've ruled out for this specific event:

No deployment/release at that time
No regional Azure Service Health incidents for our region

we found out in one of our app service instance Availability and Performance possible cause. instance was replaced around the same time. screenshots attached.

Screenshot From 2026-07-10 16-18-23

Open questions:

Given the volume of daily alerts, is there a way to distinguish, at scale, false-positive probe noise from genuine origin impact like the 9 July event — without manually cross-referencing instance history each time?
Can Microsoft identify what triggered the 9 July instance replacement (auto-heal, platform maintenance, host issue)?
Is there a known behavior where in-flight requests to an instance being drained/replaced stall near the ~60s timeout instead of failing fast or being retried on the new instance?
We're unable to submit a support ticket — the portal detects this open health event and redirects us to "resolve this first." Is there a way around this, or can a moderator escalate directly?

Alex Burlachenko 25,120 Reputation points MVP Volunteer Moderator

2026-07-13T09:22:31.17+00:00

hi Davor Teskera & thx for sharing urs issue here at Q&A portal,

the daily Resource Health events sound like generic origin health notifications, while the July 9 event appears to have been a real origin disruption. If the App Service instance was replaced at about the same time, that could explain why Front Door temporarily marked the origin unhealthy. Resource Health, however, won't tell you why the instance was replaced. Whether it was platform maintenance, host recovery, or an internal auto-heal requires backend investigation by Microsoft.

For distinguishing real incidents from probe noise, I'd correlate the Front Door Origin Health Percentage with App Service Availability and Performance, HTTP 5xx metrics, and App Service instance changes. If Origin Health drops but App Service availability, latency, and request success remain normal, it's more likely to be a transient probe event than a customer-visible outage. Regarding the ~60-second requests, yes, it's possible that requests already routed to an instance being drained can wait until the backend timeout rather than being retried on another instance. Whether that happened in your case would need confirmation from the Front Door and App Service teams.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/
Christos Panagiotidis 3,551 Reputation points

2026-07-13T12:30:46.6433333+00:00

Hi! Compare the event timestamps with Origin Health Percentage, App Service instance changes, and Front Door access logs. Verify the probe path, expected status code, protocol, host header, and timeout. A single-origin group can create noisy aggregate health events, but the July 9 event appears consistent with the App Service instance replacement you observed. A definitive platform RCA requires a support case containing the Front Door and App Service resource IDs and exact UTC time.
Davor Teskera 30 Reputation points

2026-07-13T13:17:44.9333333+00:00
hi Alex,

Thank you for your answer.

How can we get confirmation from Microsoft side regarding those 2 items:

why the instance was replaced (you mentioned that investigation by Microsoft backend team is needed) - will you check that or we need to contact someone else?

"it's possible that requests already routed to an instance being drained can wait until the backend timeout rather than being retried on another instance" - you mentioned that confirmation is needed from Front Door and App Service teams - will you get those or we need to contact someone else?

Your answer

Alex Burlachenko 25,120 Reputation points MVP Volunteer Moderator

2026-07-13T09:22:31.17+00:00

hi Davor Teskera & thx for sharing urs issue here at Q&A portal,

the daily Resource Health events sound like generic origin health notifications, while the July 9 event appears to have been a real origin disruption. If the App Service instance was replaced at about the same time, that could explain why Front Door temporarily marked the origin unhealthy. Resource Health, however, won't tell you why the instance was replaced. Whether it was platform maintenance, host recovery, or an internal auto-heal requires backend investigation by Microsoft.

For distinguishing real incidents from probe noise, I'd correlate the Front Door Origin Health Percentage with App Service Availability and Performance, HTTP 5xx metrics, and App Service instance changes. If Origin Health drops but App Service availability, latency, and request success remain normal, it's more likely to be a transient probe event than a customer-visible outage. Regarding the ~60-second requests, yes, it's possible that requests already routed to an instance being drained can wait until the backend timeout rather than being retried on another instance. Whether that happened in your case would need confirmation from the Front Door and App Service teams.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/
Christos Panagiotidis 3,551 Reputation points

2026-07-13T12:30:46.6433333+00:00

Hi! Compare the event timestamps with Origin Health Percentage, App Service instance changes, and Front Door access logs. Verify the probe path, expected status code, protocol, host header, and timeout. A single-origin group can create noisy aggregate health events, but the July 9 event appears consistent with the App Service instance replacement you observed. A definitive platform RCA requires a support case containing the Front Door and App Service resource IDs and exact UTC time.
Davor Teskera 30 Reputation points

2026-07-13T13:17:44.9333333+00:00

hi Alex,

Thank you for your answer.

How can we get confirmation from Microsoft side regarding those 2 items:

why the instance was replaced (you mentioned that investigation by Microsoft backend team is needed) - will you check that or we need to contact someone else?

"it's possible that requests already routed to an instance being drained can wait until the backend timeout rather than being retried on another instance" - you mentioned that confirmation is needed from Front Door and App Service teams - will you get those or we need to contact someone else?