HACKER Q&A
📣 bradwood

Do you implement “health endpoints” on your back end services?


This seems to be quite a common pattern, whether on specific microservices, browser-facing APIs, or elsewhere?

My question is: Do you implement these? What are the gotchas / benefits? And, what kind of data do you serve from them? Is it just basic service uptime, or a load of other stats about the "health" of your service? (If so, what)?

And further, if you have a `/health` what do you consume that endpoint with?

Thank you for your thoughts.

  👤 perrygeo Accepted Answer ✓
The health endpoints exist only to provide a signal to some external orchestrator (these days most likely kubernetes). There's rarely a need to attach any data to these responses - you can just respond with an HTTP 200 and an empty body. They're not meant to be human readable; the orchestrator will use the status code to make a decision whether to send traffic there or to restart the container, etc.

There are two variations of a health endpoint, you should consider adding them both:

A "readiness" endpoint is dead simple - is the application alive? If not, the orchestrator will shut down the application and try to restart it.

A "liveness" endpoint does more work to ensure that, e.g. you have a valid database connection and your app can actually serve real traffic. I usually connect to the db and run a simple "select 1;". If that fails, the orchestrator will reroute traffic away from this instance - but not restart it.

👤 szpasztor
Yes, we use Kubernetes / GKE and it expects it by default.

For a current project it's literally just a HTTP 200 served by the application server.

👤 jstx1
Kubernetes expects these to exist by default right?