What is a Health Check, and why is it needed?

Short answer

A health check is TR7 sending checks to Backend Services at regular intervals and measuring whether they respond. A server that fails the check is automatically taken out of traffic and taken back when it recovers; this way, users are not sent to a crashed server. In TR7, it is defined as a Health Checks profile and assigned to the Backend Service or to the Backend Group; if it is not assigned, the server's health is not monitored and the server continues to receive traffic even if it crashes.

How Does It Work?

1. A check is sent: In every Period, TR7 sends the Backend Service a check matching the Check Type in the profile (TCP connection, HTTP request, DNS query…).
2. The result is evaluated: If the expected response does not arrive within the Timeout duration, the check is considered failed.
3. Taken out of traffic: When the number of consecutive failed checks reaches the Required Failures threshold, the Backend Service is taken out of traffic; requests go to the healthy Backend Services.
4. Taken back: The Backend Service that is out of traffic continues to be checked. When the number of consecutive successful checks reaches the Required Successes threshold, it is taken back into traffic.

Parameter	Default	Meaning
Period	1 s	The interval at which checks are sent
Timeout	1 s	The maximum time a check waits for a response
Required Failures	2	Consecutive failed checks required to take the server out of traffic
Required Successes	3	Consecutive successful checks required to take the server back into traffic

Period and Timeout are kept below 120 seconds; values of 120 seconds and above are reduced to 1 second. Health checks run continuously, independently of traffic processing.

Why Is It Needed?

Without a health check	With a health check
A crashed server continues to receive traffic; some of the users see errors.	A faulty server is automatically taken out of traffic; requests go to the healthy servers.
When the server recovers, it must be taken back into traffic manually.	A recovered server is automatically taken back into traffic once the Required Successes threshold is reached.
If the server is up but the application returns errors, this is not noticed.	With an HTTP check, the status code and the response content are verified.
When the server went down is not visible.	The health status is monitored in the lists and on the Backend Service Dashboard.

Check Types

The Check Type list in the profile form contains 16 types; the type is selected when the profile is created and cannot be changed after it is saved:

Group	Types	What it checks
Connection	TCP, TCPS, UDP, Ping	Whether the port or the server responds; for TCP, TCPS and UDP, a scenario that sends data and looks for the expected response can be defined
Web	HTTP, HTTPS	Sends an HTTP request; verifies the status code and the response content
Application protocols	DNS, FTP, FTPS, LDAP, LDAPS, SMTP, SMTPS, Oracle	Protocol-specific check (DNS query, login, SQL query…)
Logical	Expression (JSONata)	Does not send a network request; evaluates a JSONata expression on device information (e.g. the device ID in the cluster, the Master/Backup role) and the time. If the expression is true, the server is considered healthy; if it is false or erroneous, it is considered down
Combined	Scenario	Combines multiple checks with and / or; the result comes from evaluating these checks together

Health Check in TR7

• Creation: The profile is defined with Load Balancer → Profiles → Health Checks → Add; the Check Type (default HTTP) and the thresholds are selected.
• Assignment: The profile is assigned from the Health Check field in the Backend Service form; the default of the field is No Check. In a Backend Group, the profile is selected once at the group level and is applied separately, with the same profile, to each server in the group.
• Status indicator: The Health indicator in the Backend Services list shows the OK (green), Error (red), Preparing (yellow) or HC disabled / No data (gray) status; for a Backend Service with no health check assigned, a dark gray power icon appears instead of the status dot.
• Network vService: The health check result is reflected in distribution for the TCP - L4 and UDP - L4 protocols while Port Range is off. In the ANY - L3 protocol or while Port range is on, the health check result is not taken into account because traffic is distributed via firewall rules; a faulty Backend Service also continues to receive packets.

Common Misconceptions

• "Even if I don't assign a health check, a faulty server is disabled." The health of a Backend Service whose health check field remains at No check is not monitored; it continues to receive traffic even if it has crashed.
• "If the port is open, the application is healthy." A TCP check only shows that the connection can be established. In web applications, verifying the status code and the content with an HTTP check also catches application errors.
• "A health check works in every Network vService." In the ANY - L3 protocol or while Port range is on, the health check result is not reflected in distribution; a faulty Backend Service continues to receive packets.
• "A Backend Group's health check checks the group as a single unit." Even though the profile is selected at the group level, each server is checked separately; only the failed server stays out of traffic.

How it is done in the documentation

• Health Checks · What Is the Health Checks Profile?
• Health Checks · The Default Health Checks Profile Behavior
• Health Checks · The Supported Health Check Types (Protocols)
• vService · Network (packet level)
• Health Checks · Recommended Values and Tuning Guide

Related questions

• What does a Health Check do; what happens if I don't assign one?
• Which health check types are supported?
• What is the difference between a TCP port check and an HTTP check; which should I choose?
• How many seconds does it take for a server to be considered "down", and how do I calculate it?