Azure App Service (Windows): Health Check Failures When Scaling Beyond 11 Instances — Workers Stuck in UNKNOWN Status

Problem description

My Azure App Service (Windows) consistently experiences Health Check degradation when autoscaling beyond 11 instances.

Newly added workers appear with **UNKNOWN **status, fail to reach a stable operational state, and eventually disappear. Health Check recovers only when the instance count returns to 11.

The main question is why scale-out works successfully up to 11 instances but consistently fails at 12 or more.

Environment

• Service: Azure App Service (Windows / IIS / WCF)
• App Service Plan: Premium V3 (P3v3)
• Autoscale: Minimum 2, maximum 20 instances
• WEBSITE_HEALTHCHECK_MAXPINGFAILURES: 2
• Unhealthy instance removal – Load balancing threshold: 2 minutes
• ARR Affinity: Disabled

What I've already tried

1. Process Explorer: Observed intermittent worker processes but no conclusive startup errors.
2. Worker lifecycle: When autoscale increases the instance count from 11 to 12, the newly added worker appears in UNKNOWN status and never reaches a stable healthy state. After approximately 70–75 minutes, the worker disappears and another one appears, showing the same behavior. This cycle repeats while the application requires 12 or more instances. Once traffic decreases, autoscale reduces the instance count from 12 to 11, and HealthCheckStatus immediately recovers. This suggests a possible worker replacement cycle, although the actual removal and replacement reasons have not been confirmed through Azure platform logs.
3. Kudu diagnostics: Unable to inspect affected workers directly because their Kudu environments were inaccessible.
4. Application and HTTP logs: Analyzed AppServiceHTTPLogs and application logs in Log Analytics. No conclusive initialization errors were found, and some affected workers had no HTTP logs during the incident.
5. Health Check metrics: Correlated HealthCheckStatus with the instance count, confirming the recurring pattern.

Current status

The root cause remains unidentified, and customer-accessible diagnostics have not explained the behavior.

I am looking for insights into possible Azure platform limitations, worker allocation or initialization issues, and automatic worker replacement.

Has anyone experienced a similar issue or identified additional diagnostics that could help determine the root cause?