I don't want to revive this discussion, but just wanted to give some ideas about my ideas when I initially started this with Bertrand (accidentally we did that together on an adapTo() some years ago).
* the idea was always to use the healthchecks to capture the application state and make it usable for consumption by a loadbalancer or any other external monitoring system. Implementing other checks (like checks for security measures being implemented) are also possible, but they have never been the primary usecase. * the way how the reporting states "OK", "WARN" and "CRITICAL" are interpreted, is totally up to the developer implementing the healthchecks and the team operating the system. While "OK" and "CRITICAL" seem quite natural, "WARN" is always ambigous. Coming with an "old-school" IT operation background, I would interprete WARN as "it's still working and can be used, but we should have a closer look at it". Nevertheless, the developer of healthchecks should have the same understanding. * The idea was always that it should be possible to change the settings during runtime manually; either to override accidentally incorrect settings or to handle unforseen situations; removing a misbehaving check from the state calculation (manually, without deployment) is definitly a usecase which should be supported. Jörg Am Do., 13. Sep. 2018 um 19:03 Uhr schrieb Stefan Seifert < sseif...@pro-vision.de>: > - currently there is some overlap between sling health checks and the new > felix system readyness framework presented [1] > - the idea is to bring this together within felix > - provide a facade for the sling healthcheck API for backwards > compatibility > > stefan > > [1] > https://adapt.to/2018/en/schedule/system-readiness-framework-makes-deployment-automation-a-breeze.html > > > -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
