Meaning
Health check endpoints are HTTP routes (commonly /health, /healthz, or /ready) that return a simple status response indicating whether a service is alive and able to handle requests. They address the pain point of orchestrators and load balancers needing a reliable, low-cost signal to decide whether to route traffic to or restart an instance. They are reached for whenever a service is deployed behind infrastructure that requires liveness and readiness probes.
Primary Function
Service health monitoring
Communicative Purpose
Enables orchestrators and load balancers to verify service availability without performing expensive business-logic checks.
Pattern
expose HTTP route returning status → orchestrator polls periodically → instance marked healthy or unhealthy
Função primária
Service health monitoring
Propósito comunicativo
Enables orchestrators and load balancers to verify service availability without performing expensive business-logic checks.
Situações de gatilho
Container orchestration: Kubernetes liveness/readiness probe configuration; Microservices: load balancer health verification before routing traffic; Cloud deployments: automated restart decisions for unresponsive instances
Contextos
Kubernetes, Docker, AWS ECS, NGINX, HAProxy, Express.js, Spring Boot, FastAPI, Flask, ASP.NET Core
Padrão
expose HTTP route returning status → orchestrator polls periodically → instance marked healthy or unhealthy
Colocados típicos
- liveness probe
- readiness probe
- /healthz endpoint
- HTTP 200 status
- JSON response
- Docker HEALTHCHECK
- Kubernetes probe
- startup probe
Substituições comuns
- TCP port check (cheaper but less informative)
- Deep health checks hitting database or cache (more thorough but slower and can cascade failures)
- External monitoring services like Pingdom (covers external reachability only)
Erros comuns
Returning 200 even when dependencies are down — causes traffic to be routed to broken instances; Performing expensive checks on every probe — overwhelms the service under high-frequency polling; Not separating liveness from readiness — a temporarily slow dependency causes unnecessary pod restarts; Exposing detailed error info in the response — leaks internal state to attackers; Forgetting startup delay — readiness probe fails before initialization completes
Similar / contraste
Liveness probe (checks if process is alive, triggers restart); Readiness probe (checks if ready to serve traffic, controls routing only); Startup probe (gives slow-starting containers time to initialize); Heartbeat (periodic signal, not HTTP-based)
Interferências
Coming from serverless (AWS Lambda): may not think about health endpoints since the platform manages lifecycle — but containerized or VM-based deployments require explicit health endpoints; Coming from desktop apps: health checks are not a concept — services run continuously and don't need availability signals
Família do chunk
- liveness probe
- readiness probe
- startup probe
- heartbeat
- circuit breaker
Nuance
When NOT to use: single-instance apps with no orchestrator, or when the platform already provides health management (e.g., AWS Lambda). Performance: probes should be O(1) and avoid hitting databases or external services to prevent cascading failures. Boundary conditions: distinguish between liveness (can the process respond?) and readiness (can it serve real traffic?) — conflating them causes restart storms.
Efeito pragmático
Enables zero-downtime deployments, automatic recovery from crashed instances, and safe traffic shifting during rolling updates.
Dica de memória
Health check endpoint: like a doctor's quick pulse check at the door — 'Are you alive and ready to see patients?' — cheap, frequent, and binary.
Upgrade path
Deep health checks with dependency verification and graceful degradation patterns
Log in to save chunks.