Hi @Jaakko, @ramceb
here are some thoughts for your consideration:

With the library approach, program flow monitoring impacts integrity adversely compared to an external entity monitoring it. There needs to be a strong argument and reliable way to make sure that the application monitoring itself is guaranteed to behave correctly w.r.t. sending the heartbeat, even in case of errors. As the concept implies, a heartbeat shall only be transmitted if program flow is correct and timely. In case an application does no longer work as expected, especially when sporadic errors like memory corruption or undefined behavior appear, how does one make sure to not send an "ok" heartbeat?
The sequence diagram for the monitoring does not go into detail (I believe "yet") about how program flow and deadline monitoring unblock the heartbeat from being sent. That's why the above statement is somewhat generic ("strong argument").
Other than talking about the efficiency of the library solution, we can think about a performance evaluation of both approaches. Less IPC calls looks promising for sure.

Edit 2025-07-02:

It can be useful to differentiate between crashed applications and applications that are unresponsive. Both do no longer send a heartbeat. The latter might not be sending it due to scheduling, for example. The resulting requirement is thus: The Launch Manager shall notice proper process crashes. In the sequence diagram, the use case "crashed application" subsumes both these options.

I'll leave another comment in #1275 for @vinodreddy-g

Health monitor library #1268

Description