ALB health checks
Application Load Balancer (ALB) continuously monitors your backend servers using health checks and automatically routes traffic away from unhealthy servers.
Health checks are enabled by default for all server groups and can be configured independently per server group.
How it works
ALB periodically sends probe requests to each backend server and evaluates the response. A server must pass a consecutive number of checks—the Healthy Threshold—before ALB marks it as healthy. This prevents transient network jitter from triggering false positives.
When a server fails checks consecutively beyond the Unhealthy Threshold, ALB stops routing new requests to it and redirects them to healthy servers. When the server recovers, ALB automatically adds it back.
Health checks use short-lived connections that close immediately after each probe completes.
Fail-open behavior: If all servers in a server group fail health checks simultaneously, ALB still routes requests to all of them based on the scheduling algorithm rather than dropping traffic entirely. This limits service disruption when a widespread failure occurs.
Backend servers with a weight of 0 do not participate in health checks.
Source IP addresses
ALB probes your backend servers from specific IP addresses. Make sure your servers allow traffic from these addresses—including in iptables rules and third-party security software. If you block these IPs, the health check probes cannot reach your servers, ALB marks them as unhealthy, and they are removed from load balancing rotation.
ALB instance type | Source IP range |
Upgraded ALB instance | Private IP addresses from the vSwitch CIDR block (Local IP). View these addresses on the instance details page. |
Non-upgraded ALB instance |
|
Create a health check
Console
Go to the Health Check page in the ALB console.
Select the target region, then click Create Health Check.
Configure the following parameters and click Create.
Basic settings
Parameter | Description |
Health Check Name | A name for this health check template. |
Protocol | The probe protocol. See Protocols for details. |
Health Check Method | The HTTP method for the probe request. Applies to HTTP, HTTPS, and gRPC only. |
HTTP Version | HTTP1.0 or HTTP1.1. Applies to HTTP and HTTPS only. |
Port | The port to probe. Leave blank to use each backend server's port. Valid values: 1–65535. |
Path | The URL path to probe, such as |
Domain name | The |
Health determination
Parameter | Default | Valid values | Description |
Health Check Status Codes |
| The HTTP status codes that indicate a healthy server. Applies to HTTP, HTTPS, and gRPC only. | |
Health Check Response Timeout | 5 seconds | 1–300 seconds | If the server does not respond within this time, the check counts as a failure. |
Health Check Interval | 2 seconds | 1–50 seconds | Time between consecutive checks. Longer intervals mean slower detection of unhealthy servers. |
Healthy Threshold | 3 | 2–10 | Consecutive successful checks required to mark a server healthy. |
Unhealthy Threshold | 3 | 2–10 | Consecutive failed checks required to mark a server unhealthy. |
Tags and resource group
Parameter | Description |
Tag Key / Tag Value | Key-value tags for filtering and managing health check templates. |
Resource Group | The resource group this health check belongs to. |
After creating the health check, select it in the Health Check Settings section when creating a server group.
You can also configure health checks when creating a server group and save the configuration as a template by selecting Save the health check configurations as a template.
API
Call CreateHealthCheckTemplate to create a health check template.
Call ApplyHealthCheckTemplateToServerGroup to apply it to a server group.
Protocols
Health check methods (HTTP, HTTPS, gRPC)
Method | Default for | Behavior |
HEAD | HTTP, HTTPS | Requests only headers. Make sure your backend supports HEAD requests; if not, use GET. |
POST | gRPC | Make sure your backend supports POST requests; if not, use GET. |
GET | — | Responses larger than 8 KB are truncated, but this does not affect the health check result. |
Protocol details
Protocol | Mechanism |
HTTP | ALB sends HEAD or GET requests to verify that the backend server application is healthy. |
HTTPS | ALB sends HEAD or GET requests to verify that the backend server application is healthy. Supported for Standard and WAF-enhanced ALB instances. Not supported for Basic ALB instances. |
TCP | ALB sends SYN handshake packets to verify that the backend server port is available. |
gRPC | ALB sends POST or GET requests to verify that the backend server application is healthy. |
Health check status codes (HTTP, HTTPS, gRPC)
ALB declares a server healthy only when the probe returns one of the configured status codes.
HTTP/HTTPS: Choose from
http_2xx,http_3xx,http_4xx, andhttp_5xx. Default:http_2xxandhttp_3xx.gRPC: Valid codes are 0–99. Specify up to 20 value ranges, separated by commas.
Including http_4xx or http_5xx in your status code list delays detection of unhealthy servers. Keep the list to http_2xx and http_3xx, and fix backend issues that cause 4XX or 5XX responses.
Modify a health check
Disabling health checks means ALB no longer detects unhealthy servers. If a server goes down, traffic is not automatically redirected to healthy servers.
If you specify a longer health check interval, more time is required for ALB to detect unhealthy backend servers.
Console
Go to the Health Check page in the ALB console.
Find the target health check and click Modify in the Actions column.
Update the settings in the Modify Health Check Settings dialog and click Save.
You can also edit health checks on the Server Groups page.
API
Call UpdateHealthCheckTemplateAttribute to update a health check template.
View health check status
If your ALB instance has listeners and health checks are enabled, view the health status of backend servers on the Listener tab.
Console
API
Call GetListenerHealthStatus to query the health check status of a listener.
Delete a health check
Console
Go to the Health Check page in the ALB console.
Find the target health check and click Delete in the Actions column.
Confirm the deletion and click OK.
API
Call DeleteHealthCheckTemplates to delete a health check template.
Apply in production
Create a dedicated health check endpoint. Add a dedicated route—such as /health—that always returns HTTP 200. Avoid using business paths: they may return 4XX due to authentication or missing resources, causing false failures.
Fix backend issues instead of relaxing status codes. When health checks fail, troubleshoot and fix the root cause so the endpoint returns 2XX or 3XX. Do not add 4XX or 5XX to the accepted status code list to work around the issue.
Tune parameters for your environment. Default settings work for most scenarios. For slow-starting services, increase the Health Check Interval or Unhealthy Threshold to avoid prematurely marking a starting server as unhealthy. For high-latency networks, increase the Health Check Response Timeout.
Simulate health checks with curl. When troubleshooting, use the following command to replicate ALB's probe behavior. Replace the method, domain, IP, port, and path to match your configuration:
curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://backend_ip:port/health_pathBilling
Health checks incur no additional charges. For ALB pricing details, see ALB billing information.
Quota
You can create up to 50 health check templates per region. This quota cannot be increased.