Update monitor-instances-health-check.md

added the 60s timeout: if the path does not return a response within 1 minute the health check ping is considered unhealthy.

### 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 returning 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](#monitoring) feature to keep track of your application's health.

### Is HealthCheck following the application code configured redirects between the default domain and the custom domain?

No, 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.

Author: rapopescu16

articles/app-service/monitor-instances-health-check.md

@@ -12,7 +12,7 @@ ms.custom: contperf-fy22q1
 
 # 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 rerouting requests away from unhealthy instances, and replacing instances if they remain unhealthy. Your [App Service plan](./overview-hosting-plans.md) 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.
+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](./overview-hosting-plans.md) 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.
 
 ![Health check failure][1]
 
@@ -140,7 +140,7 @@ After providing your application's Health check path, you can monitor the health
 
 ### 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. 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](#monitoring) feature to keep track of your application's health.
+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](#monitoring) feature to keep track of your application's health.
 
 ### Why are the Health check requests not showing in my web server logs?
 
@@ -150,6 +150,11 @@ The Health check requests are sent to your site internally, so the request won't
 
 On Windows App Service, the Health check requests will be sent via HTTPS when [HTTPS Only](configure-ssl-bindings.md#enforce-https) 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 HTTP**S** at this time.
 
+### Is HealthCheck following the application code configured redirects between the default domain and the custom domain?
+
+No, 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`](#configuration)). 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.