Health checks tell infrastructure whether an app should receive traffic. A liveness check says the process is alive. A readiness check says the app can serve requests.
A health check that always returns OK can hide broken dependencies. A health check that checks too much can create false outages.
Further Learning
“liveness readiness health checks” — health check types
“Kubernetes readiness probe” — common model
“HTTP health endpoint design” — practical endpoint design
Health Checks
A health check is a simple endpoint your server exposes that answers “are you okay?” Your hosting platform pings this regularly to decide whether to keep sending real traffic your way.
Liveness — “is the process even running?” (should I restart it?)
Readiness — “can it actually handle a real request right now?” (should I send it traffic?)
A server can be alive (the process hasn’t crashed) but not ready (its database connection isn’t set up yet). Both matter for different reasons.
Get the check itself right
WARNING
A health check that always says “ok” is useless — it hides real problems, like a broken database connection. But a health check that does too much work (running expensive queries) can slow things down or create false alarms. Keep it lightweight but meaningful — check the things that would actually stop your app from working.
In one sentence
A health check tells your hosting platform whether an instance should get traffic — keep it lightweight, but meaningful enough to actually catch broken dependencies (not just “yes, the process exists”).
Want to go deeper?
Switch to Expert mode above for liveness vs readiness probes in platforms like Kubernetes.