Server
Health check
Health check is a lightweight request made repeatedly to see whether an origin should be trusted with traffic. A pass keeps it in rotation, and enough failures remove it.
How it is measured
Define what the check requests, how often (every 5 to 30 seconds), the timeout, and how many consecutive passes or failures change its state. A common setup is a GET to /healthz, 2 seconds timeout, 3 failures to mark unhealthy, 2 passes to recover.
The status code and the response time both matter. A 200 that takes 4 seconds is a failing check under a 2 second timeout, and a check that never touches the database cannot tell you the database is gone.
Worked example
A load balancer polls /healthz on three Node origins every 10 seconds. The endpoint returns 200 if the process runs, and nothing more. When the Postgres connection drops on origin 2, it keeps returning 200 while every real request fails with 500.
Changing the endpoint to run a one-row query with a 1 second limit means origin 2 fails three checks in 30 seconds and leaves the pool. Users who were getting errors on a third of requests now see none.
How it differs
A health check asks 'is this origin okay for traffic?' A liveness probe asks 'is this process stuck and in need of a restart?' A readiness probe asks 'can it take requests right now?' A generic health check excludes the restart decision, while liveness excludes whether dependencies are reachable.
Common errors
Returning 200 without testing anything. Making the check so deep that a slow third-party call removes every origin at once. Running it on a path that needs login. Setting the timeout longer than the interval. Letting the check hit the CDN cache instead of the origin.
In practice
Write a /healthz that checks the process and one fast dependency, keep it under 200 ms, and exclude it from rate limits and logs. Run the check from your uptime monitor too so you see what the load balancer sees.