We're running the HealthChecks UI as a standalone APP which is responsible for tracking the liveliness status of multiple cross-domain applications, effectively serving as an Overwatch oracle for our entire business stack.
Even though we've configured IIS to not put the application to sleep, after 5-6 months of continuous work, the background worker that's responsible for going through these registered applications and checking their health status - your background worker - appears to be not working. After some time, it just stops polling the registered applications.
There are no error logs. There is radio silence. The application and UI are responsive, and signal that the application was never recycled or put to sleep.
We use an in-memory cache to store the data, via HealthChecksUIBuilder.AddInMemoryStorage.
You mention that you never trim or delete the data stored. Is this also true for In-memory data? If so, we theorize that at some point in time, the application's memory gets so large that it crashes your worker, but if this happens - we expect to see something written in our application logs, yet the log does not mention such critical event.
Could you verify if our theory is correct and that the only explanation for your background worker to stop doing its job is if the in-memory storage got too big?
We're running the HealthChecks UI as a standalone APP which is responsible for tracking the liveliness status of multiple cross-domain applications, effectively serving as an Overwatch oracle for our entire business stack.
Even though we've configured IIS to not put the application to sleep, after 5-6 months of continuous work, the background worker that's responsible for going through these registered applications and checking their health status - your background worker - appears to be not working. After some time, it just stops polling the registered applications.
There are no error logs. There is radio silence. The application and UI are responsive, and signal that the application was never recycled or put to sleep.
We use an in-memory cache to store the data, via
HealthChecksUIBuilder.AddInMemoryStorage.You mention that you never trim or delete the data stored. Is this also true for In-memory data? If so, we theorize that at some point in time, the application's memory gets so large that it crashes your worker, but if this happens - we expect to see something written in our application logs, yet the log does not mention such critical event.
Could you verify if our theory is correct and that the only explanation for your background worker to stop doing its job is if the in-memory storage got too big?