What is Health Checking in Networking?
Learn what health checking is — active vs passive checks, liveness vs readiness, and how unhealthy servers are removed from rotation.
Expected Interview Answer
Health checking is the process by which a load balancer or orchestrator periodically probes each backend server — via TCP connect, HTTP request, or a custom protocol check — to determine whether it is capable of serving traffic, automatically removing unhealthy servers from rotation and adding them back once they recover.
A health check can be as simple as attempting a TCP connection to a port, or as thorough as sending an HTTP GET to a dedicated endpoint like /healthz and verifying a 200 status and expected body. Checks run on a configurable interval (e.g., every 5 seconds), and a server is typically marked unhealthy only after a threshold of consecutive failures (to avoid flapping from a single transient blip) and marked healthy again only after a threshold of consecutive successes. Passive health checks complement active ones by observing real traffic — if a server starts returning 5xx errors or timing out on live requests, it can be pulled from rotation without waiting for the next active probe. Good health checks distinguish “process is running” (liveness) from “process can actually serve requests correctly” (readiness) — a server can be up but unable to reach its database, and a proper readiness check should catch that and stop sending it traffic.
- Automatically removes failing servers from the traffic rotation
- Prevents users from hitting servers that cannot serve requests correctly
- Automatically restores servers to rotation once they recover
- Distinguishes liveness (process up) from readiness (able to serve traffic)
AI Mentor Explanation
Health checking is like an umpire periodically checking each bowling machine before letting batters use it — a quick glance confirms it is plugged in and running (liveness), but a proper check also fires a test ball to confirm it actually delivers at the right speed (readiness). If a machine fails several checks in a row, it is pulled from the rotation until it passes again. This periodic probe-then-gate pattern is exactly how a load balancer decides which backend servers stay in the traffic rotation.
Step-by-Step Explanation
Step 1
Configure the probe
An interval, timeout, and success/failure threshold are set for a TCP connect, HTTP, or custom health check.
Step 2
Run periodic checks
The load balancer probes each backend on the configured interval, independent of live user traffic.
Step 3
Mark unhealthy
After the configured number of consecutive failures, the backend is removed from the active rotation.
Step 4
Restore on recovery
After the configured number of consecutive successes, the backend is added back to receive traffic again.
What Interviewer Expects
- Correct definition: periodic probing to determine backend availability
- Distinguishes active (probe-based) from passive (real-traffic-based) health checks
- Distinguishes liveness (process up) from readiness (able to serve correctly)
- Understands why consecutive-failure/success thresholds prevent flapping
Common Mistakes
- Treating a TCP connect check as sufficient proof the application layer works
- Not distinguishing liveness from readiness checks
- Using a single failed check to remove a server, causing unnecessary flapping
- Forgetting passive health checks can react faster than active probing intervals
Best Answer (HR Friendly)
“Health checking is how a system automatically keeps tabs on whether each server is actually working — it periodically pings each one, and if a server stops responding correctly, it gets pulled out of rotation so users never get sent to it. Once that server recovers and passes the check again, it is automatically added back, so the whole system stays reliable without anyone manually flipping a switch.”
Code Example
import time
import urllib.request
FAIL_THRESHOLD = 3
SUCCESS_THRESHOLD = 2
consecutive_failures = 0
consecutive_successes = 0
healthy = True
def probe(url):
try:
with urllib.request.urlopen(url, timeout=2) as resp:
return resp.status == 200
except Exception:
return False
def check_once(url):
global consecutive_failures, consecutive_successes, healthy
if probe(url):
consecutive_successes += 1
consecutive_failures = 0
if consecutive_successes >= SUCCESS_THRESHOLD:
healthy = True
else:
consecutive_failures += 1
consecutive_successes = 0
if consecutive_failures >= FAIL_THRESHOLD:
healthy = False
return healthy
# check_once("http://10.0.0.5:8080/healthz") on a 5-second intervalFollow-up Questions
- What is the difference between liveness and readiness checks?
- How do active health checks differ from passive health checks?
- Why use consecutive-failure thresholds instead of removing a server on the first failure?
- What should a well-designed /healthz endpoint actually verify?
MCQ Practice
1. What does an active health check typically involve?
Active health checks are periodic probes (TCP, HTTP, or custom) sent to backends independent of real user requests.
2. What is the purpose of a consecutive-failure threshold before marking a server unhealthy?
Requiring multiple consecutive failures prevents a single transient blip from unnecessarily pulling a healthy server out of rotation.
3. What distinguishes a readiness check from a liveness check?
Liveness confirms the process is up; readiness confirms it can actually serve traffic correctly (e.g., can reach its database).
Flash Cards
What is health checking? — Periodically probing backend servers to determine if they can serve traffic, removing unhealthy ones from rotation.
Active vs passive health checks? — Active: dedicated periodic probes. Passive: inferred from real traffic errors/timeouts.
Liveness vs readiness? — Liveness: is the process running. Readiness: can it actually serve requests correctly right now.
Why use failure thresholds? — To avoid flapping servers in and out of rotation due to single transient failures.