EQS /healthcheck starting up state
For services that support /heathcheck, long initialization before being able to respond to /healthcheck can lead to the service manager deciding that the service isn't healthy and needs to be restarted, potentially resulting in the service never getting enough time to successfully complete startup.
The solution is to start listening for the /healthcheck end point and return a status 200 and body meaning "starting". As long as it's different than the available message, it will work.
Unless something changed since I wrote this, I believe this will happen currently. The issue is, currently, the other service endpoints may also begin responding before they are fully caught up.
Moving to Deliverable 3 as we need more clarity about the problem.