Only send to healthy backends
A load balancer spreads traffic across many backend servers, but sending requests to a broken one wastes them. A health check is a periodic probe that decides whether each backend should receive traffic.
Probe and threshold
The balancer probes each backend on an interval and tracks results against thresholds:
- A backend is marked unhealthy after a configured number of consecutive failures.
- It is marked healthy again after a configured number of consecutive successes.
- Only healthy backends stay in the active pool that receives requests.
Using consecutive count thresholds rather than a single result prevents one blip from ejecting a good server or one fluke from restoring a bad one. The check itself can be a shallow TCP connect or a deeper HTTP request that exercises real logic.
Shallow versus deep
A shallow check only confirms the process is listening, which can pass while the app is broken downstream. A deeper check that touches a database catches more real failures but adds load and can cause cascading ejections if a shared dependency stutters. Choosing the depth is a balance between sensitivity and stability.
Key idea
Health checks probe backends on an interval and use consecutive success and failure thresholds to add or remove them from the active pool, balancing check depth against stability.