Azure App Service Health check

Health check increases your application's availability by rerouting requests away from unhealthy instances and replacing instances if they remain unhealthy. It does that by pinging every minute a path of the web application of your choice.

Please note that /api/health is just an example added for illustration purposes. We do not create a Health Check path by default. You should make sure that the path you are selecting is a valid path that exists within your application. The Health check path should check critical components of your application.

💡
For example, if your application depends on a database and a messaging system, the Health check endpoint should connect to those components.

If the application can't connect to a critical component, then the path should return a 500-level response code to indicate the app is unhealthy. Also, if the path does not return a response within 1 minute, the health check ping is considered unhealthy.

  • When given a path on your app, Health check pings this path on all instances of your App Service app at 1-minute intervals.

  • If an instance doesn't respond with a status code between 200-299 (inclusive) after 10 requests (by default 10 requests, you can change it in app settings or Health Check UI at the Load Balancing section), App Service determines its unhealthy and removes it from the load balancer for this Web App. The required number of failed requests for an instance to be deemed unhealthy is configurable to a minimum of two requests.

  • After removal, the Health Check continues to ping the unhealthy instance. If the instance begins to respond with a healthy status code (200-299) then the instance is returned to the load balancer.

  • If an instance remains unhealthy for one hour, it will be replaced with a new instance.

  • When scaling out, App Service pings the Health check path to ensure new instances are ready.

  • When selecting the Health check path, make sure you're selecting a path that returns a 200 status code, only when the app is fully warmed up.

  • Your App Service plan should be scaled to two or more instances to fully utilize Health check.

  • To enable Health check, browse to the Azure portal and select your App Service app.

  • Under Monitoring, select Health check.

  • Select Enable and provide a valid URL path on your application, such as /health or /api/health.

  • I prefer 5 minutes for the Load Balancing section. This means if it doesn't return 200 response for 5 minutes then it will be marked as unhealthy

  • Select Save.

Health check configuration changes restart your app. To minimize impact to production apps, we recommend configuring staging slots and swapping to production.

In addition to configuring the Health check options, you can also configure the following app settings:

WEBSITE_HEALTHCHECK_MAXPINGFAILURES

2 - 10 The required number of failed requests for an instance to be deemed unhealthy and removed from the load balancer. For example, when set to 2, your instances will be removed after 2 failed pings. (Default value is 10)

WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT

1 - 100 By default, no more than half of the instances will be excluded from the load balancer at one time to avoid overwhelming the remaining healthy instances. For example, if an App Service Plan is scaled to four instances and three are unhealthy, two will be excluded. The other two instances (one healthy and one unhealthy) will continue to receive requests. In the worst-case scenario where all instances are unhealthy, none will be excluded. To override this behavior, set app setting to a value between 1 and 100. A higher value means more unhealthy instances will be removed (default value is 50).

What is the difference between WEBSITE_HEALTHCHECK_MAXPINGFAILURES and the Load Balancing in the picture below?

There is no difference. The portal offers a better UI experience for setting WEBSITE_HEALTHCHECK_MAXPINGFAILURES. Both represent the total amount of time in minutes of getting failed pings before App Service determines it is unhealthy and removes it, because;

Health check pings this path on all instances of your App Service app at 1-minute intervals.

For more information :

https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check?tabs=dotnet

https://stackoverflow.com/questions/71851966/azure-app-service-website-healthcheck-maxpingfailures-and-time-of-load-balanci