Monitor App Service instances using Health check
This article uses Health check in the Azure portal to monitor App Service instances. Health check increases your application's availability by removing unhealthy instances. Your App Service plan should be scaled to two or more instances to use Health check. 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 cannot connect to a critical component, then the path should return a 500-level response code to indicate the app is unhealthy.
What App Service does with Health checks
- 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 two or more requests, or fails to respond to the ping, the system determines it's unhealthy and removes it.
- After removal, Health check continues to ping the unhealthy instance. If it continues to respond unsuccessfully, App Service restarts the underlying VM in an effort to return the instance to a healthy state.
- If an instance remains unhealthy for one hour, it will be replaced with new instance.
- Furthermore, when scaling up or out, App Service pings the Health check path to ensure new instances are ready.
Health check doesn't follow 302 redirects. At most one instance will be replaced per hour, with a maximum of three instances per day per App Service Plan.
Enable 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
- Click 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:
|App setting name||Allowed values||Description|
||2 - 10||The maximum number of ping failures. For example, when set to
||0 - 100||To avoid overwhelming healthy instances, no more than half of the instances will be excluded. For example, if an App Service Plan is scaled to four instances and three are unhealthy, at most 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
Authentication and security
Health check integrates with App Service's authentication and authorization features. No additional settings are required if these security features are enabled. However, if you're using your own authentication system, the Health check path must allow anonymous access. If the site is HTTPS-Only enabled, the Health check request will be sent via HTTPS.
Large enterprise development teams often need to adhere to security requirements for exposed APIs. To secure the Health check endpoint, you should first use features such as IP restrictions, client certificates, or a Virtual Network to restrict application access. You can secure the Health check endpoint by requiring the
User-Agent of the incoming request matches
ReadyForRequest/1.0. The User-Agent can't be spoofed since the request would already secured by prior security features.
After providing your application's Health check path, you can monitor the health of your site using Azure Monitor. From the Health check blade in the Portal, click the Metrics in the top toolbar. This will open a new blade where you can see the site's historical health status and create a new alert rule. For more information on monitoring your sites, see the guide on Azure Monitor.