Getting more 502 Bad Gateway from Front Door to Docker Container webapp

Question

Getting more 502 Bad Gateway from Front Door to Docker Container webapp

dstj1 0

I'm wondering if other are experiencing the same thing. Starting August 21th, 2026 I'm seeing more HTTP 502 Bad Gateway errors from Azure Front Door on API requests that just pass-through to my backend server (see graph below). I'm trying to understand the cause and need help / ideas in identifying if it's an Azure problem or a "me" problem.

My setup is pretty simple: Azure Front Door --> 1 replica of Docker Container ASP.NET 10 Webapp (2 CPU Cores / 4 GB RAM)

What I know:

The 502 started appearing about 20-25 days after the previous deployment (end of July)
Usage (requests, users, etc.) is pretty uniform throughout the time period.
A new deployment (i.e. container restart) on Sept 2 did not fix the problem
Requests are not received by the origin server.
Retries within the same second are successful.
Does not seem to be related to distance to server

Azure Service Health reported a EastUS 2 App Maintenance during that time time period: https://app.azure.com/h/TR8B-WGG/bc37b5 (no clue if that could explain it).

I also see some health probes failures, but timing does not seem to correlate to 502s.

Any ideas on what to check for possible explanations?

502 Errors

AzureDiagnostics
| where Category == "FrontDoorAccessLog" and TimeGenerated > ago(30d)
| where httpStatusCode_s == "502"
| summarize count() by errorInfo_s, bin(TimeGenerated, 6h)
| render timechart title="Types of HTTP 502 errors by AFD errorInfo_s"

Health Probes

AzureDiagnostics
| where Category == 'FrontDoorHealthProbeLog'
| where TimeGenerated > ago(30d)
| summarize count() by result_s, bin(TimeGenerated, 6h)
| render timechart title="Health Probes failures"

0 comments

1 answer

Your answer

Answer 1

A few details in your description point to one specific cause rather than anything Front Door is doing incorrectly.

You are running a single App Service instance, and you mentioned an App Maintenance advisory for East US 2 during the same time window. That is the most likely explanation. Azure App Service performs automated updates and maintenance on instances in your plan. When an instance is replaced, there is a short period where the old instance is gone and the new instance is not yet ready. During that gap, Front Door cannot reach the origin and returns 502.

This matches everything you observed. Requests do not reach the origin because there is briefly no instance to receive them. Retries succeed within the same second because the replacement instance has already come online. Redeploying on September 2 does not change the fact that you only have one instance for the platform to rotate. Health probe timing does not correlate because the probe runs on its own schedule and can easily miss a gap that lasts only a few seconds.

To confirm this, rerun your 502 chart with a smaller bin size, such as 5 to 15 minutes, and compare it to the exact timestamps of the App Maintenance advisory. If the 502 spikes fall inside that window, that is strong evidence.

It would also help to post the errorInfo_s values from your query. OriginConnectionRefused or OriginConnectionAborted with a very short timeTaken fits the instance replacement theory. ResponseTimedOut would indicate a different issue, which does not match your observation that retries succeed instantly.

If this is the cause, the fix is simple. Scale your App Service plan to at least two instances. Front Door has no visibility into your instance count and only health checks the single origin endpoint you configured. With two or more instances, the App Service platform can take one out of rotation for updates without interrupting traffic. If you are on a Premium plan, enabling zone redundancy adds another layer of protection.

There is one secondary scenario worth ruling out. Sometimes Front Door reuses a pooled connection at the same moment the origin closes it, which produces a fast 502 with no logs on the origin. If your errorInfo_s values show OriginConnectionAborted and the timing does not match the maintenance window, try disabling HTTP/2 between Front Door and the origin and check your Origin Response Timeout setting.

If you can share the errorInfo_s breakdown and a finer grained timechart, it will be much easier to confirm the exact cause.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.