What Is a Health Check? Liveness, Readiness, and Monitoring

A health check is a request sent to a service to confirm it's running and responding correctly. In its simplest form, it's an HTTP endpoint (often /health or /healthz) that returns a 200 status code when everything is operational and an error code when something is wrong. Load balancers, container orchestrators like Kubernetes, and monitoring tools all use health checks to decide whether a service instance should receive traffic.

Health checks split into two categories. A liveness check answers "is the process running?" — it catches crashed or hung services. A readiness check answers "can this instance handle requests right now?" — it catches services that are technically alive but still starting up, waiting on a database connection, or otherwise unable to serve traffic. Kubernetes uses both: a failed liveness check restarts the pod, a failed readiness check removes it from the load balancer without killing it.

Health checks vs. heartbeats

The terms overlap but the direction is different. A health check is a pull — an external system asks the service "are you OK?" and reads the response. A heartbeat (used in cron job monitoring) is a push — the job itself reports "I just ran" by pinging a monitoring endpoint. Health checks work well for long-running services that are always available to be polled. Heartbeats work better for scheduled tasks that run briefly, do their work, and exit.

Health checks and monitoring

External uptime monitoring is essentially a health check run from outside your infrastructure on a schedule. The monitor sends an HTTP request to your endpoint, checks for the expected status code, and measures the response time. If the check fails — timeout, wrong status, or no response — alerts fire. Running these checks from multiple regions catches issues that a single internal health check would miss: DNS problems, CDN failures, or regional network outages.

Related terms: uptime, cron job, SLA, observability