Health Check

A health check is typically implemented as a dedicated, lightweight API endpoint (e.g., /health or /ready) that returns a simple status code. This endpoint performs internal diagnostics without triggering core business logic.

• Key Response Codes: HTTP 200 OK for healthy, 503 Service Unavailable for unhealthy.
• Lightweight: Must execute quickly with minimal resource consumption to avoid becoming a performance bottleneck.
• Separation of Concerns: Distinct from metrics or status endpoints, focusing purely on binary operational readiness.

Modern orchestration systems like Kubernetes define two primary types of health checks, each serving a distinct purpose in the service lifecycle.

• Liveness Probe: Answers "Is the process running?" A failure triggers a container restart. This catches deadlocks or hung processes.
• Readiness Probe: Answers "Is the service ready to accept traffic?" A failure removes the pod from the load balancer pool. This handles temporary unreadiness, such as during startup or when a critical dependency (like a database) is temporarily unavailable.

A comprehensive health check validates the status of downstream dependencies, ensuring the service can fulfill its intended function. This is a core differentiator from a simple process check.

• Deep vs. Shallow Checks: A shallow check may only verify the service process. A deep check tests connections to databases, caches, message queues, and other essential APIs.
• Circuit Breaker Integration: Health status can be integrated with the Circuit Breaker Pattern; a failing dependency may trip the circuit, which the health check then reflects.
• Cascading Failure Prevention: By failing readiness when a critical dependency is down, the health check prevents the service from accepting traffic it cannot process, averting a cascading failure.

Health checks are the primary signal used by infrastructure components to make automated routing and lifecycle decisions.

• Load Balancers: Use health checks to determine which backend instances (pods, VMs) receive traffic. Unhealthy instances are automatically drained.
• Service Meshes & API Gateways: Tools like Istio or NGINX use health checks for similar traffic management and failover strategies.
• Orchestrators: Platforms like Kubernetes, Nomad, or ECS use liveness/readiness probes to manage container lifecycle, ensuring automatic recovery and smooth deployments during blue-green or canary deployments.

The behavior of a health check is governed by timing parameters that balance responsiveness with stability, preventing false positives from transient network blips.

• Period (Interval): How often the check is executed (e.g., every 10 seconds).
• Timeout: The maximum duration allowed for the check to complete before it is considered a failure (e.g., 2 seconds).
• Success/Failure Thresholds: The number of consecutive successes or failures required to change the overall health status (e.g., 3 failures to mark unhealthy). This adds hysteresis, preventing flapping.

For complex services, a health check may execute a synthetic transaction—a simplified but representative operation that validates the full stack.

• Example: For a payment service, a health check might create a test payment against a sandbox gateway and immediately void it.
• Advantage: Provides higher confidence than a simple connectivity check, as it validates business logic paths.
• Consideration: Must be carefully designed to have zero side effects on production data or state, often leveraging dedicated test accounts or idempotent operations.