Allow health indicators to run with a specified timeout

[philwebb]

Originally discussed in #4391 for datasource timeouts, but the problem is more broadly applicable to all health indicators.

[gf-smtzgr]

This would be neat.
You might also want to separate the status computation from the status retrieval in addition to timeouts. Imho the retrieval of a system status should not be affected by the system status, i.e. if database answers are slow that should not mean the health check should be slow. Thus, ideally a separate thread (pool) regularly updates the health status such that the request handling just needs to readout the current status flags rather than do the status checks to answer the request.

[wilkinsona]

Thus, ideally a separate thread (pool) regularly updates the health status such that the request handling just needs to readout the current status flags rather than do the status checks to answer the request.

That's #25459.

[gf-smtzgr]

@wilkinsona thanks! then I can follow that, too.

[jesperronn]

Thanks for bringing this up. In real life we are now seing /actuator/health with 15+ health indicators. When 10 indicators times out even with a low timeout of 2s its a sequential latency problem, and potentially affecting other probes in the infrastructure.

Therefore I think it would be really important if this feature could land. I imagine each healthindicator having its own cache key value including staleness invalidation (configurable parameter).

Looking at suggestion at branch from @wilkinsona, i think its getting a big step in the right direction. Dont really think its missing that much to be useful.

So regarding the api and design decisions missing, could you consider to land this discussion soon?

If it needs more time (open since 2021), please advise if or how to make an extension that could help this issue?

ping @wilkinsona @philwebb

[mhalbritter]

I've already started working on this, and I hope to get it into Spring Boot 4.2.0. 🤞