Consider splitting healthcheck into readiness check and liveness checks
Currently, Render uses the healthcheck endpoint for two distinct purposes (cf. https://render.com/docs/deploys#health-checks):
- during deploys, to check that the newly deployed service is ready to accept incoming traffic
- during the service's lifetime, to check if the service needs to be restarted
In many cases, the readiness check might need to check several subsystems (e.g. check that all data stores can be reached, that there are no pending DB migrations, etc.), while the liveness check is usually only concerned with fringe situations like deadlocks and can typically be implemented as a trivial handler that always returns 200.
(This suggestion is inspired by Kubernetes' readiness vs. liveness probes: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)