Monitor the health of App Service instances - Azure App Service (2023)

  • Article
  • 8 minutes to read

This article uses Health check in the Azure portal to monitor App Service instances. Health check increases your application's availability by rerouting requests away from unhealthy instances, and replacing instances if they remain unhealthy. Your App Service plan should be scaled to two or more instances to fully utilize 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 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.

Monitor the health of App Service instances - Azure App Service (1)

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 10 requests, App Service determines it's unhealthyand removes it. (The required number of failed requests for an instance to be deemed unhealthy is configurable to a minimum of two requests.)
  • After removal, 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 new instance.
  • When scaling out, App Service pings the Health check path to ensure new instances are ready.


(Video) Troubleshooting instance related issues on Azure App Services

  • 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.
  • If your health check is giving the status Waiting for health check response then the check is likely failing due to an HTTP status code of 307, which can happen if you have HTTPS redirect enabled but have HTTPS Only disabled.

Enable Health Check

Monitor the health of App Service instances - Azure App Service (2)

  • 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.
  • 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:

App setting nameAllowed valuesDescription
WEBSITE_HEALTHCHECK_MAXPINGFAILURES2 - 10The 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_MAXUNHEALTHYWORKERPERCENT1 - 100By 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 0 and 100. A higher value means more unhealthy instances will be removed (default value is 50).

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.

(Video) Betatalks #57 - How to set up Health Checks in Azure App Service

If you're using your own authentication system, the Health check path must allow anonymous access. 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. Once you have those features in-place, you can authenticate the health check request by inspecting the header, x-ms-auth-internal-token, and validating that it matches the SHA256 hash of the environment variable WEBSITE_AUTH_ENCRYPTION_KEY. If they match, then the health check request is valid and originating from App Service.

  • .NET
  • Python
  • Java
  • Node.js
using System;using System.Text;/// <summary>/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY./// </summary>public Boolean HeaderMatchesEnvVar(string headerValue) { var sha = System.Security.Cryptography.SHA256.Create(); String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY"); String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar))); return hash == headerValue;}


The x-ms-auth-internal-token header is only available on Windows App Service.


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, select the Metrics in the top toolbar. This will open a new blade where you can see the site's historical health status and option to create a new alert rule. Health check metrics will aggregate the successful pings & display failures only when the instance was deemed unhealthy based on the health check configuration. For more information on monitoring your sites, see the guide on Azure Monitor.

(Video) How to identify and diagnose apps with high CPU: Part 1 | Azure App Service


  • Health check can be enabled for Free and Shared App Service Plans so you can have metrics on the site's health and setup alerts, but because Free and Shared sites can't scale out, any unhealthy instances won't be replaced. You should scale up to the Basic tier or higher so you can scale out to 2 or more instances and utilize the full benefit of Health check. This is recommended for production-facing applications as it will increase your app's availability and performance.

Frequently Asked Questions

What happens if my app is running on a single instance?

If your app is only scaled to one instance and becomes unhealthy, it will not be removed from the load balancer because that would take down your application entirely. However, after one hour of continuous unhealthy pings, the instance is replaced. Scale out to two or more instances to get the rerouting benefit of Health check. If your app is running on a single instance, you can still use Health check's monitoring feature to keep track of your application's health.

Why are the Health check requests not showing in my web server logs?

The Health check requests are sent to your site internally, so the request won't show in the web server logs. This also means the request will have an origin of since the request is being sent internally. You can add log statements in your Health check code to keep logs of when your Health check path is pinged.

Are the Health check requests sent over HTTP or HTTPS?

On Windows App Service, the Health check requests will be sent via HTTPS when HTTPS Only is enabled on the site. Otherwise, they're sent over HTTP. On Linux App Service, the health check requests are only sent over HTTP and can't be sent over HTTPS at this time.

Is Health check following the application code configured redirects between the default domain and the custom domain?

No, the Health check feature is pinging the path of the default domain of the web application. If there is a redirect from the default domain to a custom domain, then the status code that Health check is returning is not going to be a 200 but a redirect (301), which is going to mark the worker unhealthy.

What if I have multiple apps on the same App Service Plan?

Unhealthy instances will always be removed from the load balancer rotation regardless of other apps on the App Service Plan (up to the percentage specified in WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT). When an app on an instance remains unhealthy for over one hour, the instance will only be replaced if all other apps with Health check enabled are also unhealthy. Apps that don't have Health check enabled won't be taken into account.


Imagine you have two applications (or one app with a slot) with Health check enabled, called App A and App B. They are on the same App Service Plan and that the Plan is scaled out to four instances. If App A becomes unhealthy on two instances, the load balancer will stop sending requests to App A on those two instances. Requests will still be routed to App B on those instances assuming App B is healthy. If App A remains unhealthy for over an hour on those two instances, those instances will only be replaced if App B is also unhealthy on those instances. If App B is healthy, the instance won't be replaced.

(Video) Diagnosing application crashes with Azure App Services

Monitor the health of App Service instances - Azure App Service (3)


If there were another site or slot on the Plan (Site C) without Health check enabled, it would not be taken into consideration for the instance replacement.

What if all my instances are unhealthy?

In the scenario where all instances of your application are unhealthy, App Service will remove instances from the load balancer up to the percentage specified in WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT. In this scenario, taking all unhealthy app instances out of the load balancer rotation would effectively cause an outage for your application.

Does Health Check work on App Service Environments?

Yes, health check is available for the App Service Environment v3, but not for versions 1 or 2. If you are using the older versions of the App Service Environment, you can use the migration feature to migrate your App Service Environment to version 3.

(Video) Health Checks in .NET Core - Part III | UI & Azure Integration | #ui #azure #appservice #frontdoor

Next steps


1. Understanding Azure App Services
2. What to use for monitoring your applications in Azure | Azure Friday
(Microsoft Azure)
3. Scaling a Spring Boot app using Azure App Service Environment v3
(Microsoft DevRadio)
4. Azure App Service (Web Apps) Tutorial
(Adam Marczak - Azure for Everyone)
5. How to automatically scale Azure App Services | Azure Tips and Tricks
(Microsoft Azure)
6. How to use Azure Log Monitoring for your .NET Web Apps
(Microsoft Azure)
Top Articles
Latest Posts
Article information

Author: Roderick King

Last Updated: 05/17/2023

Views: 6253

Rating: 4 / 5 (51 voted)

Reviews: 90% of readers found this page helpful

Author information

Name: Roderick King

Birthday: 1997-10-09

Address: 3782 Madge Knoll, East Dudley, MA 63913

Phone: +2521695290067

Job: Customer Sales Coordinator

Hobby: Gunsmithing, Embroidery, Parkour, Kitesurfing, Rock climbing, Sand art, Beekeeping

Introduction: My name is Roderick King, I am a cute, splendid, excited, perfect, gentle, funny, vivacious person who loves writing and wants to share my knowledge and understanding with you.