What is a health check endpoint?
What it should check
A basic health check returns HTTP 200 with a small response when the app process is alive. A deeper check can also confirm that the database connection works, but keep it fast. A slow health endpoint can cause false alarms when the server is only busy.
Avoid returning sensitive details like versions, database passwords or internal hostnames. A plain OK or a small JSON object with a status field is usually enough.
- Returns HTTP 200 when healthy
- Responds quickly, ideally well under a second
- Does not require a login
- Optionally checks key dependencies like the database
How it is used
Load balancers remove unhealthy servers from rotation based on this check. Container orchestrators can restart containers that stop responding to it. Uptime monitors call it on a schedule and send an alert after repeated failures.
Set the check interval and failure threshold carefully. Checking every few seconds with a one-failure alert can create noise during brief spikes. Document the endpoint in your README so teammates know what it checks and what a healthy response looks like. Test it with a simple curl request from another machine to confirm it responds the same way outside the server.
Common mistakes
- Making the health check hit the full site, which makes it slow and fragile.
- Exposing internal details publicly on the health URL.
- Triggering a restart or paging someone after a single failed check.
