Health check endpoint

A tiny URL, conventionally /health or /healthz, that something polls every few seconds. Who is asking matters more than the URL, because a failure means something different to each caller. A failed readiness probe takes the instance out of the load balancer's rotation, so requests go to its siblings until it recovers. A failed liveness probe tells the orchestrator the process is wedged, and typically gets it restarted. A deploy gate polling the same path decides whether a new instance is safe to promote, and halts or reverses the rollout when it is not. An external uptime monitor usually just alerts a human. One 200, four different consequences, and it is worth knowing which one you are wiring up.

That difference drives what each check should actually do. Liveness should check almost nothing: can this process answer at all. Point it at the database and a slow database becomes a restart loop across your whole fleet. Readiness can be stricter: connection pool up, required startup work finished, caches warm. Rolling and blue-green deploys both lean on readiness to know when a new instance is safe to receive traffic.

Gotcha: a health check that pings every downstream dependency turns one flaky third-party API into a cascading self-inflicted outage, because every instance marks itself unhealthy at once. Keep it cheap, give it a hard timeout, never require auth on it, exclude it from your request logs and analytics, and do not make it so shallow that it returns 200 from a process that cannot actually serve a single real request.