A health endpoint sounds almost too simple.
Something like:
GET /health
But this tiny endpoint can become extremely useful in production.
What Should It Do?
At the simplest level:
{ "status": "ok" }
The important part is that it should be fast and predictable.
Don't Turn It Into a Full Diagnostic System
A health endpoint shouldn't perform expensive operations every time it is called.
Avoid making it:
Run large queries Call ten external APIs Generate reports Perform expensive calculations
Health checks may run frequently.
Keep them lightweight.
Liveness and Readiness
You can also separate:
Liveness
Is the application process alive?
Readiness
Is the application ready to receive traffic?
This distinction can be valuable in containerized applications.
Why Platforms Use Health Checks
A platform needs a reliable way to determine whether a new container is ready.
Hostwares supports configurable health check paths and uses health checks during deployment before switching traffic to a new container.
A Good Endpoint Is Boring
That's exactly what you want.
GET /health → 200 OK
No complex logic.
No authentication surprises.
No slow database query unless your architecture specifically requires a dependency check.
Just a reliable signal.
The best health endpoint is usually the one that does almost nothing—and always answers correctly.