Release Notes and Announcements
- Release Notes
Product Introduction
Purchase Guide
- Billing Overview
- Billable Items
- Purchase Methods
- Overdue Payments
Getting Started
Operation Guide
- ALB Instances
- ALB Listeners
- ALB Target Groups
- ALB Health Checks
- ALB Monitoring Alarms
- ALB Access Management
API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Target Group APIs
- Shared Bandwidth Package APIs
- Security Policy APIs
- Other APIs
- Listener APIs
- Instance APIs
- Health Check Template APIs
- Forwarding Rule APIs
- Data Types
- Error Codes
FAQs
- Configurations
Contact Us
Glossary

Configuring a Health Check

Download

Focus Mode

Font Size

Last updated: 2026-09-28 16:39:10

AI-Translated

The health check feature is the core mechanism for Application Load Balancer (ALB) to ensure service high availability. After you enable the health check feature, ALB continuously probes the operating status of each backend service in the target group. It automatically forwards client requests only to the backend services that pass the health check. When a backend service becomes abnormal, ALB automatically removes it from traffic distribution. After the backend service recovers, ALB automatically resumes it for traffic distribution. This process prevents single point of failures (SPOFs) from affecting the overall business.
This document describes the working mechanism of an ALB health check and the meanings of its parameters and how to configure and modify a health check in the console.
Prerequisites
An ALB instance has been created. If it is not created, create one by referring to Creating an ALB Instance.
A target group has been created, and backend services have been added to it. If it is not created, create one by referring to Creating and Managing a Target Group.
Health Check Working Mechanism
ALB allows you to configure a health check from the target group dimension. For each target group, a health check can be independently enabled and configured with its own policy. The working mechanism is as follows:
After you enable a health check, ALB periodically sends probe requests from its health probe source IP address to each backend service in the target group. ALB determines the health statuses of the backend services based on the response results.
A backend service is considered healthy only after it passes a specified number of consecutive successful probes (the healthy threshold). This prevents misjudgments caused by network jitters. Conversely, if a backend service fails a specified number of consecutive probes (the unhealthy threshold), it is considered abnormal.
When a backend service is determined to be abnormal, ALB automatically removes it from traffic distribution. New requests are distributed to other healthy backend services based on the scheduling policy. When the service recovers, ALB automatically resumes it for traffic distribution.
Health Check uses non-persistent connections for probing. The connection is closed after each probe is completed.
When all backend services in a target group are abnormal, ALB still attempts to forward requests to these services based on the scheduling policy. This aims to minimize the risk of a complete service outage.
Note:
Backend services with a weight of 0 do not receive new requests and participate in health checks.
Health Check Methods
An ALB target group supports the following health check methods. The available options for these methods are linked to the backend protocol of the target group.
When the backend protocol is HTTP or HTTPS, the supported health check methods are TCP, HTTP, and HTTPS.
When the backend protocol is gRPC, the supported health check methods are TCP and gRPC.
When the backend protocol is gRPCs, the supported health check methods are TCP and gRPCs.
Check Method
Check Principle
Applicable Scenarios
TCP
Initiates a TCP three-way handshake (SYN packet) with the backend service to probe whether the port is alive, only verifying port connectivity without sensing the application-layer status.
Suitable for scenarios where the backend is a generic TCP service or only port reachability needs to be confirmed. It has low performance overhead and is the default health check method.
HTTP
Sends an HTTP request (HEAD or GET) to a backend service and determines whether the backend application is normal based on the returned HTTP status code.
Suitable for scenarios where the backend is an HTTP application and service availability needs to be confirmed at the application layer.
HTTPS
Sends a TLS-encrypted HTTP request to a backend service and determines whether the backend application is normal based on the returned HTTP status code.
Suitable for scenarios where the backend is an HTTPS application and service availability needs to be confirmed over an encrypted link.
gRPC
Sends a gRPC health check request to a backend service and determines whether the backend application is normal based on the returned gRPC status code.
Suitable for scenarios where the backend is a gRPC application.
gRPCs
Sends a TLS-encrypted gRPC health check request to a backend service and determines whether the backend application is normal based on the returned gRPC status code.
Suitable for scenarios where the backend is an encrypted gRPCs application.
Configuring a Health Check
A health check can be configured when you create a target group and can be edited after the target group is created. This section uses the Configure Health Check step in the target group creation workflow as an example.
1. Log in to the ALB console. In the left sidebar, choose ALB > Target Group Management.
2. After a region is selected at the top of the page, click Create. In the Create Target Group dialog box, configure parameters in the Basic Information section and click Next: Configure Health Check.
3. In the Configure Health Check step, configure health check parameters based on the table below. After the configuration is completed, click Finish.
Basic Parameter
Parameter
Description
Health Check
Determine whether to enable the health check. After it is enabled, ALB automatically checks for and removes abnormal backend services. It is recommended that you keep it enabled.
Check Method
Select the protocol used for the health check. The available options are linked to the backend protocol of the target group:
When the backend protocol is HTTP or HTTPS, the supported health check methods are TCP, HTTP, and HTTPS.
When the backend protocol is gRPC, the supported health check methods are TCP and gRPC.
When the backend protocol is gRPCs, the supported health check methods are TCP and gRPCs.
Check Port
Enter the port used for health check probes. It defaults to the port of the backend service. If the health check port of the backend service differs from the business port, you can specify a dedicated port here.
Leave it empty unless otherwise required.
HTTP/HTTPS Health Check Method-Specific Parameters
When the check method is HTTP or HTTPS, you also need to configure the following application-layer parameters in addition to the basic parameters:
Parameter
Description
Check Domain Name
It can contain 1–80 characters.
It is the forwarding domain name by default.
Regular expressions are not supported. If your forwarding domain name is a wildcard domain name, you need to specify a fixed (non-regular) domain name as the health check domain name.
Supported character sets include letters (a–z), digits (0–9), periods (.), and hyphens (-).
Check Path
Set the health check path to the backend server root directory or a specified URL:
It can contain 1–200 characters.
The path name starts with / by default and is required to start with /.
Regular expressions are not supported. It is recommended that you specify a fixed URL path (static page) for the health check.
Supported character sets include lowercase letters (a–z), uppercase letters (A–Z), digits (0–9), and the following special characters: .-_/=?
HTTP Request Method
Select an HTTP request method for the health check. Valid values: GET and HEAD. Default value: HEAD.
If the HEAD method is used, the server only returns the HTTP header information, which can reduce backend overhead and improve request efficiency. The corresponding backend service needs to support HEAD.
If the GET method is used, the backend service only needs to support GET.
HTTP Status Code Detection
Use a set of response status codes to determine whether the backend service is alive. If a probe returns any status code in this set, the service is considered alive. You can select http_1xx, http_2xx, http_3xx, http_4xx, and http_5xx. When the returned status code matches any selected category, the real server is considered alive.
gRPC/gRPCs Health Check Method-Specific Parameters
When the health check method is gRPC or gRPCs, you also need to configure the following parameters in addition to the basic parameters:
Parameter
Description
Check Domain Name
It can contain 1–80 characters.
It is the forwarding domain name by default.
Regular expressions are not supported. If your forwarding domain name is a wildcard domain name, you need to specify a fixed (non-regular) domain name as the health check domain name.
Supported character sets include letters (a–z), digits (0–9), periods (.), and hyphens (-).
Check Path
When the gRPC protocol is selected for health checks, the path defaults to /TCLOUD.CLB/healthcheck, and can also be customized in the /Package.Class/method format.
gRPC Status Code Detection
The gRPC status code used to determine whether the backend service is alive. Default value: 12. Value range: 0–99.
The input value can be a single digit, multiple digits, a range, or a combination, for example, 20, 20,25, 0–99, or a combination of 12, 25, 30–40. The real server is considered alive when the gRPC status code returned matches the configured status code.
Advanced Options
Click Show Advanced Options to adjust the health check probe frequency and judgment threshold by using the slider:
Parameter
Description
Value Range
Default Value
Response Timeout Period
The maximum wait period for a single health check. If the backend service does not respond correctly within this period, the probe is marked as failed.
2–60 (seconds)
2 (seconds)
Detection Interval
The time interval between 2 consecutive health checks. A shorter interval leads to quicker anomaly detection but higher probing overhead.
2–300 (seconds)
5 (seconds)
Unhealthy Threshold
After the number of consecutive probe failures reaches this threshold, the backend service is marked as abnormal and traffic is drained from it.
2–10 (times)
3 (times)
Healthy Threshold
After the number of consecutive successful probes reaches this threshold, the backend service is marked as healthy and traffic is restored to it.
2–10 (times)
3 (times)
Note:
The response timeout period must be less than the detection interval. If the backend service starts slowly, you can appropriately increase the detection interval or the unhealthy threshold to prevent it from being incorrectly judged as abnormal during startup. If the network latency is high, you can appropriately increase the response timeout period.
Viewing the Health Check Status
After you enable health check for a target group and associate it with a listener, you can view the health check status of each backend service on the listener management tab.
1. Log in to the ALB console and locate the target instance.
2. After you go to the target instance details page, switch to the listener management tab. You can view the health status in the Health Check Status column. The meanings of the health check statuses for a backend service are as follows:
Status
Description
Healthy
The backend service passes consecutive health checks (meeting the healthy threshold) and normally participates in traffic distribution.
Abnormal
The backend service fails consecutive health checks (meeting the unhealthy threshold) and has been drained from traffic distribution.
Unknown
No backend service exists in the bound target group.
Probing
The status of a newly bound real server within the check interval multiplied by the healthy threshold.
Disabled
The health check status (disabled). ALB forwards traffic to all backend services.
Modifying a Health Check
After a target group is created, you can modify its health check configurations at any time.
1. In the target group management list, click the target group ID to go to the details page.
2. In the Health Check section on the Basic Information page, click Edit.
3. After the modification is completed, click Save.
Attention:
After you disable the health check, ALB no longer probes backend services. If a backend service fails, traffic cannot be automatically switched to other healthy backend services. This may cause service disruption. Proceed with caution.
Increasing the detection interval prolongs the time it takes to detect an abnormal backend service. Configure this interval appropriately based on your business requirements for failover timeliness.

Help and Support

Was this page helpful?

You can also Contact sales or Submit a Ticket for help.

Help us improve! Rate your documentation experience in 5 mins.

Feedback

Check Method	Check Principle	Applicable Scenarios
TCP	Initiates a TCP three-way handshake (SYN packet) with the backend service to probe whether the port is alive, only verifying port connectivity without sensing the application-layer status.	Suitable for scenarios where the backend is a generic TCP service or only port reachability needs to be confirmed. It has low performance overhead and is the default health check method.
HTTP	Sends an HTTP request (HEAD or GET) to a backend service and determines whether the backend application is normal based on the returned HTTP status code.	Suitable for scenarios where the backend is an HTTP application and service availability needs to be confirmed at the application layer.
HTTPS	Sends a TLS-encrypted HTTP request to a backend service and determines whether the backend application is normal based on the returned HTTP status code.	Suitable for scenarios where the backend is an HTTPS application and service availability needs to be confirmed over an encrypted link.
gRPC	Sends a gRPC health check request to a backend service and determines whether the backend application is normal based on the returned gRPC status code.	Suitable for scenarios where the backend is a gRPC application.
gRPCs	Sends a TLS-encrypted gRPC health check request to a backend service and determines whether the backend application is normal based on the returned gRPC status code.	Suitable for scenarios where the backend is an encrypted gRPCs application.

Parameter	Description
Health Check	Determine whether to enable the health check. After it is enabled, ALB automatically checks for and removes abnormal backend services. It is recommended that you keep it enabled.
Check Method	Select the protocol used for the health check. The available options are linked to the backend protocol of the target group: When the backend protocol is HTTP or HTTPS, the supported health check methods are TCP, HTTP, and HTTPS. When the backend protocol is gRPC, the supported health check methods are TCP and gRPC. When the backend protocol is gRPCs, the supported health check methods are TCP and gRPCs.
Check Port	Enter the port used for health check probes. It defaults to the port of the backend service. If the health check port of the backend service differs from the business port, you can specify a dedicated port here. Leave it empty unless otherwise required.

Parameter	Description
Check Domain Name	It can contain 1–80 characters. It is the forwarding domain name by default. Regular expressions are not supported. If your forwarding domain name is a wildcard domain name, you need to specify a fixed (non-regular) domain name as the health check domain name. Supported character sets include letters (a–z), digits (0–9), periods (.), and hyphens (-).
Check Path	Set the health check path to the backend server root directory or a specified URL: It can contain 1–200 characters. The path name starts with / by default and is required to start with /. Regular expressions are not supported. It is recommended that you specify a fixed URL path (static page) for the health check. Supported character sets include lowercase letters (a–z), uppercase letters (A–Z), digits (0–9), and the following special characters: .-_/=?
HTTP Request Method	Select an HTTP request method for the health check. Valid values: GET and HEAD. Default value: HEAD. If the HEAD method is used, the server only returns the HTTP header information, which can reduce backend overhead and improve request efficiency. The corresponding backend service needs to support HEAD. If the GET method is used, the backend service only needs to support GET.
HTTP Status Code Detection	Use a set of response status codes to determine whether the backend service is alive. If a probe returns any status code in this set, the service is considered alive. You can select http_1xx, http_2xx, http_3xx, http_4xx, and http_5xx. When the returned status code matches any selected category, the real server is considered alive.

Parameter	Description	Value Range	Default Value
Response Timeout Period	The maximum wait period for a single health check. If the backend service does not respond correctly within this period, the probe is marked as failed.	2–60 (seconds)	2 (seconds)
Detection Interval	The time interval between 2 consecutive health checks. A shorter interval leads to quicker anomaly detection but higher probing overhead.	2–300 (seconds)	5 (seconds)
Unhealthy Threshold	After the number of consecutive probe failures reaches this threshold, the backend service is marked as abnormal and traffic is drained from it.	2–10 (times)	3 (times)
Healthy Threshold	After the number of consecutive successful probes reaches this threshold, the backend service is marked as healthy and traffic is restored to it.	2–10 (times)	3 (times)

Status	Description
Healthy	The backend service passes consecutive health checks (meeting the healthy threshold) and normally participates in traffic distribution.
Abnormal	The backend service fails consecutive health checks (meeting the unhealthy threshold) and has been drained from traffic distribution.
Unknown	No backend service exists in the bound target group.
Probing	The status of a newly bound real server within the check interval multiplied by the healthy threshold.
Disabled	The health check status (disabled). ALB forwards traffic to all backend services.

tencent cloud

Application Load Balancer

Configuring a Health Check

Prerequisites

Health Check Working Mechanism

Health Check Methods

Configuring a Health Check

Viewing the Health Check Status

Modifying a Health Check

Help and Support