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

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.