# Health checks for Application Load Balancer target groups Your Application Load Balancer periodically sends requests to its registered targets to test their status. These tests are called *health checks*. Each load balancer node routes requests only to the healthy targets in the enabled Availability Zones for the load balancer. Each load balancer node checks the health of each target, using the health check settings for the target groups with which the target is registered. After your target is registered, it must pass one health check to be considered healthy. After each health check is completed, the load balancer node closes the connection that was established for the health check. If a target group contains only unhealthy registered targets, the load balancer routes requests to all those targets, regardless of their health status. This means that if all targets fail health checks at the same time in all enabled Availability Zones, the load balancer fails open. The effect of the fail-open is to allow traffic to all targets in all enabled Availability Zones, regardless of their health status, based on the load balancing algorithm. Health checks do not support WebSockets. For more information, see [Target group health](load-balancer-target-groups.md#target-group-health). You can use health check logs to capture detailed information about the health checks made to your registered targets for your load balancer and store them as log files in Amazon S3. You can use these health check logs to troubleshoot issues with your targets. For more information, see [Health check logs](load-balancer-health-check-logs.md). **Topics** + [Health check settings](#health-check-settings) + [Target health status](#target-health-states) + [Health check reason codes](#target-health-reason-codes) + [Check target health](check-target-health.md) + [Update health check settings](modify-health-check-settings.md) ## Health check settings You configure health checks for the targets in a target group as described in the following table. The setting names used in the table are the names used in the API. The load balancer sends a health check request to each registered target every **HealthCheckIntervalSeconds** seconds, using the specified port, protocol, and health check path. Each health check request is independent and the result lasts for the entire interval. The time that it takes for the target to respond does not affect the interval for the next health check request. If the health checks exceed **UnhealthyThresholdCount** consecutive failures, the load balancer takes the target out of service. When the health checks exceed **HealthyThresholdCount** consecutive successes, the load balancer puts the target back in service. Note that when you deregister a target, this decreases **HealthyHostCount** but does not increase **UnhealthyHostCount**. | Setting | Description | | --- | --- | | **HealthCheckProtocol** | The protocol the load balancer uses when performing health checks on targets. For Application Load Balancers the possible protocols are HTTP and HTTPS. The default is the HTTP protocol. These protocols use the HTTP GET method to send health check requests. | | **HealthCheckPort** | The port the load balancer uses when performing health checks on targets. The default is to use the port on which each target receives traffic from the load balancer. | | **HealthCheckPath** | The destination for health checks on the targets. If the protocol version is HTTP/1.1 or HTTP/2, specify a valid URI (/*path*?*query*). The default is /. If the protocol version is gRPC, specify the path of a custom health check method with the format `/package.service/method`. The default is `/AWS.ALB/healthcheck`. | | **HealthCheckTimeoutSeconds** | The amount of time, in seconds, during which no response from a target means a failed health check. The range is 2–120 seconds. The default is 5 seconds if the target type is `instance` or `ip` and 30 seconds if the target type is `lambda`. | | **HealthCheckIntervalSeconds** | The approximate amount of time, in seconds, between health checks of an individual target. The range is 5–300 seconds. The default is 30 seconds if the target type is `instance` or `ip` and 35 seconds if the target type is `lambda`. | | **HealthyThresholdCount** | The number of consecutive successful health checks required before considering an unhealthy target healthy. The range is 2–10. The default is 5. | | **UnhealthyThresholdCount** | The number of consecutive failed health checks required before considering a target unhealthy. The range is 2–10. The default is 2. | | **Matcher** | The codes to use when checking for a successful response from a target. These are called **Success codes** in the console. If the protocol version is HTTP/1.1 or HTTP/2, the possible values are from 200 to 499. You can specify multiple values (for example, "200,202") or a range of values (for example, "200-299"). The default value is 200. If the protocol version is gRPC, the possible values are from 0 to 99. You can specify multiple values (for example, "0,1") or a range of values (for example, "0-5"). The default value is 12. | ## Target health status Before the load balancer sends a health check request to a target, you must register it with a target group, specify its target group in a listener rule, and ensure that the Availability Zone of the target is enabled for the load balancer. Before a target can receive requests from the load balancer, it must pass the initial health checks. After a target passes the initial health checks, its status is `Healthy`. The following table describes the possible values for the health status of a registered target. | Value | Description | | --- | --- | | `initial` | The load balancer is in the process of registering the target or performing the initial health checks on the target. Related reason codes: `Elb.RegistrationInProgress` \$1 `Elb.InitialHealthChecking` | | `healthy` | The target is healthy. Related reason codes: None | | `unhealthy` | The target did not respond to a health check or failed the health check. Related reason codes: `Target.ResponseCodeMismatch` \$1 `Target.Timeout` \$1 `Target.FailedHealthChecks` \$1 `Elb.InternalError` | | `unused` | The target is not registered with a target group, the target group is not used in a listener rule, the target is in an Availability Zone that is not enabled, or the target is in the stopped or terminated state. Related reason codes: `Target.NotRegistered` \$1 `Target.NotInUse` \$1 `Target.InvalidState` \$1 `Target.IpUnusable` | | `draining` | The target is deregistering and connection draining is in process. Related reason code: `Target.DeregistrationInProgress` | | `unavailable` | Health checks are disabled for the target group. Related reason code: `Target.HealthCheckDisabled` | ## Health check reason codes If the status of a target is any value other than `Healthy`, the API returns a reason code and a description of the issue, and the console displays the same description. Reason codes that begin with `Elb` originate on the load balancer side and reason codes that begin with `Target` originate on the target side. For more information about possible causes for health check failures, see [Troubleshooting](load-balancer-troubleshooting.md#target-not-inservice). | Reason code | Description | | --- | --- | | `Elb.InitialHealthChecking` | Initial health checks in progress | | `Elb.InternalError` | Health checks failed due to an internal error | | `Elb.RegistrationInProgress` | Target registration is in progress | | `Target.DeregistrationInProgress` | Target deregistration is in progress | | `Target.FailedHealthChecks` | Health checks failed | | `Target.HealthCheckDisabled` | Health checks are disabled | | `Target.InvalidState` | Target is in the stopped state Target is in the terminated state Target is in the terminated or stopped state Target is in an invalid state | | `Target.IpUnusable` | The IP address cannot be used as a target, as it is in use by a load balancer | | `Target.NotInUse` | Target group is not configured to receive traffic from the load balancer Target is in an Availability Zone that is not enabled for the load balancer | | `Target.NotRegistered` | Target is not registered to the target group | | `Target.ResponseCodeMismatch` | Health checks failed with these codes: [*code*] | | `Target.Timeout` | Request timed out | # Check the health of your Application Load Balancer targets You can check the health status of the targets registered with your target groups. For help with health check failures, see [Troubleshooting: A registered target is not in service](load-balancer-troubleshooting.md#target-not-inservice). You can use health check logs to capture detailed information about the health checks made to your registered targets for your load balancer and store them as log files in Amazon S3. You can use these health check logs to troubleshoot issues with your targets. For more information, see [Health check logs](load-balancer-health-check-logs.md). ------ #### [ Console ] **To check the health of your targets** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. The **Details** tab displays the total number of targets, plus the number of targets for each health status. 1. On the **Targets** tab, the **Status** column indicates the status of each target. 1. If the status is any value other than `Healthy`, the **Status details** column contains more information. **To receive email notifications about unhealthy targets** Use CloudWatch alarms to trigger a Lambda function to send details about unhealthy targets. For step-by-step instructions, see the following blog post: [Identifying unhealthy targets of your load balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/identifying-unhealthy-targets-of-elastic-load-balancer/). ------ #### [ AWS CLI ] **To check the health of your targets** Use the [describe-target-health](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-target-health.html) command. This example filters the output to include only targets that are not healthy. For targets that are not healthy, the output includes a reason code. ``` aws elbv2 describe-target-health \ --target-group-arn target-group-arn \ --query "TargetHealthDescriptions[?TargetHealth.State!='healthy'].[Target.Id,TargetHealth.State,TargetHealth.Reason]" \ --output table ``` The following is example output. ``` ---------------------------------------------- | DescribeTargetHealth | +--------------+---------+-------------------+ | 172.31.0.57 | unused | Target.NotInUse | | 172.31.0.50 | unused | Target.NotInUse | +--------------+---------+-------------------+ ``` ------ ## Target states and reason codes The following list shows the possible reason codes for each target state. **Target state is healthy** A reason code is not provided. **Target state is initial** + `Elb.RegistrationInProgress` - The target is in the process of being registered with the load balancer. + `Elb.InitialHealthChecking` - The load balancer is still sending the target the minimum number of health checks required to determine its health status. **Target state is unhealthy** + `Target.ResponseCodeMismatch` - The health checks did not return an expected HTTP code. + `Target.Timeout` - The health check requests timed out. + `Target.FailedHealthChecks` - The load balancer received an error while establishing a connection to the target or the target response was malformed. + `Elb.InternalError` - The health checks failed due to an internal error. **Target state is unused** + `Target.NotRegistered` - The target is not registered with the target group. + `Target.NotInUse` - The target group is not used by any load balancer or the target is in an Availability Zone that is not enabled for its load balancer. + `Target.InvalidState` - The target is in the stopped or terminated state. + `Target.IpUnusable` - The target IP address is reserved for use by a load balancer. **Target state is draining** + `Target.DeregistrationInProgress` - The target is in the process of being deregistered and the deregistration delay period has not expired. **Target state is unavailable** + `Target.HealthCheckDisabled` - Health checks are disabled for the target group. # Update the health check settings of an Application Load Balancer target group You can update the health check settings for your target group at any time. For the list of health check settings, see [Health check settings](target-group-health-checks.md#health-check-settings). ------ #### [ Console ] **To update the health check settings** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Health checks** tab, choose **Edit**. 1. On the **Edit health check settings** page, modify the settings as needed. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the health check settings** Use the [modify-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group.html) command. The following example updates the **HealthyThresholdCount** and **HealthCheckTimeoutSeconds** settings. ``` aws elbv2 modify-target-group \ --target-group-arn target-group-arn \ --healthy-threshold-count 3 \ --health-check-timeout-seconds 20 ``` ------ #### [ CloudFormation ] **To update the health check settings** Update the [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the updated health check settings. The following example updates the **HealthyThresholdCount** and **HealthCheckTimeoutSeconds** settings. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: HTTP Port: 80 TargetType: instance VpcId: !Ref myVPC HealthyThresholdCount: 3 HealthCheckTimeoutSeconds: 20 ``` ------