What Is a Health Check Endpoint? Proving a Service Is Ready
A health check endpoint is a URL a service exposes, often at /health, that returns a quick signal of whether the service is alive and ready to accept traffic.
Infrastructure needs a simple way to ask a service "are you okay?" A health check endpoint answers that with a fast response that load balancers and orchestrators poll. Deploys gate the cutover on these checks: traffic shifts to a new version only once its health endpoint reports ready.
A simple readiness signal
The endpoint returns 200 when healthy and an error status otherwise. It should be cheap and fast, checking just enough to confirm the service can serve requests.
Liveness versus readiness
- Liveness: is the process alive, or should it be restarted?
- Readiness: can it serve traffic right now?
- Startup: has it finished initializing yet?
Who polls it
Load balancers poll to decide routing, and orchestrators like Kubernetes poll to decide restarts and traffic. A backend that fails its check is removed from rotation automatically.
Health checks in deploys
A safe deploy waits for new instances to pass their health checks before shifting traffic and draining old ones. This is what makes rolling and blue-green deploys zero-downtime.
CI smoke checks
After deploying, a pipeline often hits the health endpoint to confirm the release is live before marking the deploy successful. A non-200 there fails the deploy step early.
Transient during warmup
Right after a deploy, a health endpoint may briefly return non-200 while the service warms up. Latchkey runners retry transient health-check failures during verification so a slow warmup does not falsely fail a deploy.
Key takeaways
- A health check endpoint reports whether a service is alive and ready to serve.
- Load balancers and orchestrators poll it to gate traffic and restarts.
- A brief non-200 during warmup is transient, unlike a persistent failure.