Health Check
A health check is a periodic probe that determines whether a service instance is able to handle traffic. Load balancers, orchestrators (Kubernetes), and service meshes use health checks to route traffic only to healthy instances. Types: liveness (is the process alive?), readiness (can it serve requests?), and startup (has it finished initializing?).
Definition
Health checks are probes that verify service availability. A health check endpoint (typically GET /health or GET /healthz) returns HTTP 200 when the service can handle requests and 503 when it cannot. The probe can verify: database connectivity, cache availability, disk space, downstream dependency reachability, and internal state consistency. Kubernetes defines three probe types: liveness (restart the pod if it fails – detect deadlocks), readiness (remove from service if it fails – detect temporary inability to serve), and startup (give slow-starting apps time before liveness kicks in). Load balancers (ALB, Nginx, HAProxy) use health checks to remove failed backends from the pool. Probe parameters: interval (how often to check), timeout (how long to wait), threshold (failures before marking unhealthy), and success threshold (successes before marking healthy again). A health check that always returns 200 regardless of internal state provides false confidence – validate actual functionality.
Examples
- –Kubernetes: livenessProbe: { httpGet: { path: /healthz, port: 8080 }, periodSeconds: 10 }
- –ALB health check: path=/health, interval=30s, unhealthyThreshold=3
- –app.get('/health', (req, res) => db.ping().then(() => res.sendStatus(200)).catch(() => res.sendStatus(503)))
Related Protocols
Related Terms
Load Balancer
A load balancer distributes incoming traffic across multiple backend servers to prevent any single server from becoming overwhelmed. Layer 4 (TCP) load balancers route by IP/port. Layer 7 (HTTP) load balancers can route by URL path, headers, or cookies. Health checks remove failed backends automatically.
Circuit Breaker
A circuit breaker stops calling a failing downstream service after a threshold of errors, preventing cascade failures. States: Closed (normal flow), Open (all calls fail-fast without attempting), Half-Open (limited test calls to check recovery). Prevents a slow/failing service from consuming all caller resources and propagating failure upstream.
Graceful Degradation
Graceful degradation allows a system to continue operating with reduced functionality when components fail, rather than failing completely. A site with a failed recommendation engine still shows products. A service with a failed cache still queries the database (slower but functional). Requires identifying which features are optional.