Healthchecks integration

[federicotravaini]

First of all, thank you for the amazing job.
Are you planning to add an HealthChecks integration?

[zkmusa]

I would also be really interested in integrated HTTP healthchecks integration.

In the meantime, I think we can use the Shoutrr integration "generic" service to call Healthchecks. I was going to explore this some more.

[zkmusa]

It was actually much easier than I expected. The shoutrr URL is quite simple to create. Just replace "https://" with "generic://". I created a separate notification for "success" notifications and a notification for "fail" notifications.

[nicotsx]

Hello, could you be more precise? What do you mean by healtcheck integration?

[federicotravaini]

Sorry for not pointing out exactly what I was referring to.
I think you're right, if shoutrrr works, then we could just explain in the documentation how to implement healthchecks.io and nothing more.

[alxbd]

Hello @nicotsx
I’m new to this discussion, and to zerobyte (thanks for the work btw!), but I wanted to share that I would personally find a generic “Healthcheck Webhook” notification type very useful in Zerobyte.

Most healthcheck services (Healthchecks.io, Uptime Kuma, Checkly, etc.) all work the same way: a simple HTTP request to a unique URL on success/failure. A single built-in “Healthcheck Webhook” notification in zerobyte could therefore support all of them without being provider-specific.

I’d be happy to implement this myself and open a PR if you’d be open to the idea, it would avoid the need for a Shoutrrr middleware while staying generic and reusable.

Here is how it looks like on the other side (the healthcheck service), only waiting for a GET or POST request after a successful backup:

Best

[nicotsx]

@alxbd, thanks for your message. A simple POST request to webhook endpoint would do it? You can do it already with the shoutrrr custom url which zerobyte supports. Maybe if it's too complex we can add a form to help you? Is there something blocking you?

[alxbd]

Hello @nicotsx , thanks for getting back to me and taking the time. After a bit of digging, I finally understood that Uptime Kuma accepts POST requests but seems to reject the ones sent via shoutrrr using the "TEST" button :

It seems content type is set as application/json but the body is plain text, maybe preventing parsing.

When adding ?template=json to the shoutrrr URL, the body is in JSON:

-> And Uptime Kuma accept it.

Related issue: containrrr/shoutrrr#448

While it's finally working on my side, it involved some digging. Not sure if you wish to guide the users a bit more on zerobyte side, or if we consider it as a shoutrrr/Uptime Kuna "issue".

Solutions could involve:

• Having a "Using a Heartbeat Uptime monitor?" section in the shoutrrr notification type config screen with a bit more explanation and "tips"
• Having a dedicated "Heartbeat webhook" type, see example below, PR ready, but I understand it's could be seen as redundant to shoutrrr.

Best
Alex

[nicotsx]

Thanks @alxbd for the details and the testing.

I'm not against adding a new notification type in the frontend as long as the backend uses shoutrrr to send it.

If we can avoid someone to read external docs it's better!