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

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.