Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
Greetings for the day, Thanks for reaching out to Q&A.
I reviewed the concern regarding using Automatic Scaling together with Health Check in Azure App Service.
The confusion comes from an older blog post that recommended not enabling Health Check with Automatic Scaling. That guidance was applicable when the feature was still in preview. With the generally available version of Azure App Service, Automatic Scaling and Health Check are supported together.
The reason for the earlier recommendation is that Automatic Scaling uses its own internal health probes (which is why you may see /admin/host/ping entries in the App Service HTTP logs). These internal probes are different from the customer-configured Health Check feature. Health Check is only used to detect unhealthy instances, route traffic away from them, and replace them if necessary. It is not used to trigger scaling decisions.
Although the documentation does not explicitly state "Health Check and Automatic Scaling can be enabled together," the current documentation no longer lists them as incompatible. In fact, the Health Check documentation mentions that Azure App Service pings the configured Health Check endpoint during scale-out to verify that new instances are ready before serving traffic.
Based on this, I recommend the following:
- Enable Automatic Scaling on your Premium v2–v4 App Service Plan and disable ARR Affinity (Session Affinity), as ARR Affinity can keep user sessions tied to a single instance and reduce the benefits of scaling.
- Enable Health Check by configuring a warm-up endpoint that:
- Returns HTTP 200 only when the application and its required dependencies are fully ready.
- Allows anonymous access.
- Does not redirect requests.
- Validate the configuration by performing a load test and confirming that:
- The
AutomaticScalingInstanceCountmetric increases during increased load.- Instances remain healthy without restart loops or unexpected unhealthy states during scale-out and scale-in.
- The
- Allows anonymous access.
- Returns HTTP 200 only when the application and its required dependencies are fully ready.
If your application is container-based, I also recommend setting WEBSITES_CONTAINER_START_TIME_LIMIT=300 (or higher if required) and ensuring that the application listens on 0.0.0.0:$PORT. This helps prevent startup timing issues when new instances are created during scale-out.
For reference, you can review the following Microsoft documentation:
- Automatic Scaling in Azure App Service: https://learn.microsoft.com/en-us/azure/app-service/manage-automatic-scaling
- Health Check in Azure App Service: https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check
If you find these inputs useful, please accept this as answer and upvote.
Thanks,