Public /healthcheck endpoint

[feyst]

Summary

I would like to monitor my environment using an uptime monitor (for example Uptime Kuma). It would be nice if there would be a public endpoint that checks the status of all services and returns 200 status if all services are up and 500 something if any service is not working as expected.

Motivation

This way I can respond quicker if any service is having problems.

Additional context

Thanks for the awesome work!

[BigPig22]

I would love to see this. The problem with the current monitoring via watchdog is that this is internal monitoring only. If for whatever reason the watchdog service fails or Internet or DNS goes down there will be no notification.

Active external monitoring will be much more reliable and having an endpoint for that rather then checking general reachability of the server would be awesome.

[mrclschstr]

Active external monitoring will be much more reliable...

Perhaps a little off-topic: I would like the watchdog to be linked to an external service, such as https://healthchecks.io/.

Regular pings to healthchecks.io would ensure the function of the watchdog and information about malfunctions could be communicated via the status codes and logs. The idea is not new either: #228 (comment)

[DerLinkman]

Could be thought about...

I personally don't think there is anything against it technically...

[craeckor]

It's not exactly what you want but it returns kind of the same result...
In Mailcow, there is an API (/api) for some stuff, and also for Status. So, what I did is following:
First, I activated the Read-Only API under System --> Configuration --> Access --> Administrators --> API. This will give you an API-Key.
Second, I added a HTTP(s) - Json Query in Uptime Kuma. In there, I've set the URL to https://mail.example.com/api/v1/get/status/containers, the Json Query to ("ofelia-mailcow"."state" = "running") and ("netfilter-mailcow"."state" = "running") and ("rspamd-mailcow"."state" = "running") and ("acme-mailcow"."state" = "running") and ("nginx-mailcow"."state" = "running") and ("postfix-mailcow"."state" = "running") and ("mysql-mailcow"."state" = "running") and ("clamd-mailcow"."state" = "running") and ("olefy-mailcow"."state" = "running") and ("solr-mailcow"."state" = "running") and ("sogo-mailcow"."state" = "running") and ("unbound-mailcow"."state" = "running"), the expected value to true and in the Headers section, I added this

{
    "X-API-Key": "Your-API-Key"
}

You can leave the rest to default. I recommend you to add your Uptime Kuma IP to the API access.

[NoirPi]

It's not exactly what you want but it returns kind of the same result...
In Mailcow, there is an API (/api) for some stuff, and also for Status. So, what I did is following:
First, I activated the Read-Only API under System --> Configuration --> Access --> Administrators --> API. This will give you an API-Key.
Second, I added a HTTP(s) - Json Query in Uptime Kuma. In there, I've set the URL to https://mail.example.com/api/v1/get/status/containers
You can leave the rest to default. I recommend you to add your Uptime Kuma IP to the API access.

That's exactly what I did and it worked great.

Haven't found any reason for a healthcheck route if the API already provides status information on each container... That would be a limited alternative for something already existing.

Maybe some changes on the information of the container the api atm returns would be something to consider but the need for an extra endpoint isn't something I can see in the future.

[craeckor]

It's not exactly what you want but it returns kind of the same result...
In Mailcow, there is an API (/api) for some stuff, and also for Status. So, what I did is following:
First, I activated the Read-Only API under System --> Configuration --> Access --> Administrators --> API. This will give you an API-Key.
Second, I added a HTTP(s) - Json Query in Uptime Kuma. In there, I've set the URL to https://mail.example.com/api/v1/get/status/containers
You can leave the rest to default. I recommend you to add your Uptime Kuma IP to the API access.

That's exactly what I did and it worked great.

Haven't found any reason for a healthcheck route if the API already provides status information on each container... That would be a limited alternative for something already existing.

Maybe some changes on the information of the container the api atm returns would be something to consider but the need for an extra endpoint isn't something I can see in the future.

Happy to see that it works.