Health checks are the mechanism your load balancer uses to determine whether each backend server is healthy and able to handle traffic. When a backend server fails a health check, the load balancer automatically stops sending it traffic. When the server recovers and passes health checks again, it is automatically added back to the pool.
Without health checks, the load balancer would send traffic to failed servers, causing errors for your users. Properly configured health checks are essential for a reliable, high-availability setup.
How Health Checks Work
The load balancer periodically sends a test request (or probe) to each backend server. Based on the response (or lack thereof), it marks each server as:
- Healthy — The server responded correctly within the timeout period. The load balancer continues sending traffic to it.
- Unhealthy — The server did not respond, responded too slowly, or returned an error. The load balancer stops sending traffic to it.
Types of Health Checks
TCP Health Check
The simplest health check. The load balancer attempts to establish a TCP connection to the backend server on a specified port.
- Pass: TCP connection is established successfully.
- Fail: Connection refused or timed out.
HTTP Health Check
The load balancer sends an HTTP request to a specified URL path and checks the response.
- Pass: Server responds with a successful HTTP status code (typically 200 OK).
- Fail: Server returns an error code (500, 503), does not respond, or times out.
HTTPS Health Check
Same as HTTP health check but uses an encrypted HTTPS connection. Use this when your backend servers require HTTPS communication.
Health Check Parameters
When configuring health checks on your Data Mammoth load balancer, you can adjust the following parameters:
Protocol
Choose the health check type: TCP, HTTP, or HTTPS.
Recommendation: Use HTTP health checks for web applications. Use TCP for non-HTTP services (databases, game servers, etc.).
Port
The port to check on the backend server. This should match the port your application listens on (e.g., 80 for HTTP, 443 for HTTPS, or a custom application port).
Path (HTTP/HTTPS Only)
The URL path the load balancer requests during the health check (e.g., /, /health, /healthz, /status).
Recommendation: Use a dedicated health check endpoint (like /health) rather than your application's homepage. A dedicated endpoint can check internal dependencies (database connectivity, disk space, etc.) and respond more quickly.
Check Interval
How often the load balancer sends a health check probe, in seconds.
- Short interval (5-10 seconds): Faster detection of failures but more frequent probes.
- Long interval (30-60 seconds): Fewer probes but slower failure detection.
Timeout
How long the load balancer waits for a response before considering the check failed, in seconds.
- The timeout must be shorter than the check interval.
- A timeout of 5 seconds is appropriate for most applications.
Healthy Threshold
The number of consecutive successful health checks required before a previously unhealthy server is marked as healthy again.
- Higher threshold = more confidence the server is truly recovered.
- Lower threshold = faster recovery.
Unhealthy Threshold
The number of consecutive failed health checks required before a healthy server is marked as unhealthy.
- Higher threshold = more tolerance for transient failures.
- Lower threshold = faster failover.
Configuring Health Checks
Example: Web Application Health Check
| Parameter | Value |
|---|---|
| Protocol | HTTP |
| Port | 80 |
| Path | /health |
| Check Interval | 10 seconds |
| Timeout | 5 seconds |
| Healthy Threshold | 3 |
| Unhealthy Threshold | 3 |
Creating a Health Check Endpoint
For the most reliable health monitoring, create a dedicated health check endpoint in your application.
Simple Health Check
Returns HTTP 200 if the application process is running:
GET /health → 200 OKThis is better than checking the homepage because it is lightweight, fast, and does not trigger unnecessary application logic.
Comprehensive Health Check
Checks internal dependencies and returns detailed status:
GET /health → 200 OK
{
"status": "healthy",
"database": "connected",
"disk_space": "ok",
"uptime": "3d 14h 22m"
}If any critical dependency fails:
GET /health → 503 Service Unavailable
{
"status": "unhealthy",
"database": "connection failed",
"disk_space": "ok"
}A comprehensive health check ensures the load balancer only sends traffic to servers that are fully operational — not just running but actually able to serve requests.
Health Check Endpoint Best Practices
- Keep it fast. The health check endpoint should respond in under 100ms. Do not perform expensive operations.
- Check critical dependencies only. Test database connectivity, cache availability, and essential external services. Do not check optional or non-critical components.
- Return appropriate HTTP status codes. 200 for healthy, 503 for unhealthy.
- Do not require authentication. The load balancer needs to access the health endpoint without login credentials.
- Exclude from logging (optional). Health check requests are frequent and can clutter your access logs. Consider excluding the health path from logging.
Monitoring Health Check Status
Your Data Mammoth dashboard shows the health status of each backend server:
- Green / Healthy — The server is passing health checks and receiving traffic.
- Red / Unhealthy — The server is failing health checks and not receiving traffic.
- Yellow / Pending — The server was recently added or is transitioning between states.
Troubleshooting Health Check Failures
All Servers Showing Unhealthy
- Check the health check path. Make sure the URL path exists and returns HTTP 200. Test it manually:
curl http://203.0.113.10/health - Check the health check port. Ensure it matches the port your application listens on.
- Check the firewall. The load balancer needs to reach your backend servers on the health check port. Verify your cloud firewall rules allow traffic from the load balancer.
One Server Frequently Going Unhealthy
- Check server resources. High CPU, memory, or disk usage can cause slow responses that exceed the health check timeout. See Optimizing VPS Performance.
- Check application logs. Look for errors or exceptions that might cause the health endpoint to fail.
- Increase the timeout. If the server is slow but functional, temporarily increase the timeout while you investigate performance.
Server Removed from Pool but Still Running
- The server is failing health checks even though it appears to be running. SSH into the server and test the health endpoint locally:
curl localhost/health - If the local test works but the load balancer check fails, there may be a network or firewall issue between the load balancer and the server.
What to Do Next
- How to Set Up a Load Balancer — Complete load balancer setup guide.
- Load Balancing Algorithms Explained — Optimize traffic distribution.
- Configuring SSL with Your Load Balancer — Add HTTPS to your load-balanced setup.
- Troubleshooting — Server Not Responding — Diagnose server issues flagged by health checks.