[cybrox]

This seems very nice and clean, I like it!

A tangent: This style of status page and the goal that most of these projects (like this) try to achieve is always displaying the uptime of a service based on some HTTP request. In how many cases is this actually the whole story? GitHub can serve perfectly fine HTTP content, it's still broken without git via ssh. Amazon can have their site up but if payments aren't being processed, that's worth nothing.

This is not a complaint against this specific project but am I the only one that feels that this style of status page that "has been around since the mid 2010s" rarely ever tells the full story of a service's health?

[yellowsir]

Well of course, there can still be bugs in the code even if 200 is returned.

I always implement a /~/healthcheck route which will return the exit code of each check, but also encodes it in the HTTP STATUS. if any error is detected the status will be 500 if any warning is detected it will be 200+<numberOfWarnings> of course checks still need to be written, e.g. a code needs to verify that it can connect to ssh and is greeded with the correct login msg.

still there could be problems for outcomming connections.