When you released version 1.2.0 of the proxy I can admit I only did a functional test, didn't review the changelog in detail. I have some ideas I would like to share with you, I think they can be useful from a hosting perspective. Right now you are doing async calls in the healthcheck endpoint, I would rather see that you have a background worker or similar that retrieves the data periodically and store it. When calling the healthcheck return the stored data directly, non blocking. The issue arises when you lose connection to the API and the proxy is geolocated in a really remote part of the world. The pod can the be restarted multiple times when hitting the timeout value, and it can be hard to set a reasonable timeout value depending on the location. I had pods restarting several hundred times due to this, and I really don't want to increase the timeout value any more 😀 I would also like to see a liveness endpoint (/healthcheck/live) that is non blocking, non async, that just directly returns if the application is alive or not. Regards

Thanks for the feedback! I'll share it with the team.

Hi Jonas, I am currently working on the liveness configuration for the GrowthBook service that we have on aks and I haven't found clear references in the documentation about a default endpoint for healthchecks. I would like to ask for your help and insights on how to correctly configure this endpoint. We have been experiencing recurring problems where the API service stops responding, and our main objective is to implement a mechanism that automatically restarts the pod when this occurs. Your previous experience with this challenge would be very valuable to us.