[bartekrutkowski]

This adds a short section to the notifications how-to that shows how to send start, success and failure pings to a heartbeat (dead man's switch) monitoring service. #159 asked for this, and the setup there was never added to the docs.

Because NOTIFICATION_URLS sends success and failure to the same URLs, the example uses a generic shoutrrr URL for the failure ping only, and exec labels on the backup container for the start and success pings. The success ping sits on prune-post, so it is only sent when archive, process and copy have succeeded.

Tested with v2.50.1 against Watchgoose:

• successful manual and scheduled runs send start, then success
• a failing copy (archive mounted read-only) sends start, then the failure notification with the log output, and no success ping

The example uses Watchgoose URLs. Any service with separate start, success and fail URLs works the same way, including healthchecks.io.

Disclosure: I'm the founder of Watchgoose. I'm happy to keep this section accurate going forward. We also have an Open Source program with free plans for maintainers, and we'll list the project on our third-party resources page.

[m90]

Thanks for disclosing your affiliation upfront, which leads me to the ugly details: I'm not too fond of putting your service's URL in the examples, even if alternatives are mentioned.

Here's my proposal: how about writing the examples targeting a self-hosted instance of healtchecks (e.g. health.mydomain.com or something) and then mentioning hosted offerings like yours or healthchecks.io. I would think this is a bit more in line with the spirit of this tool.

Thank you for taking the time to work on this and I hope my concerns aren't too annoying.

[bartekrutkowski]

Thanks for the honest feedback, and no worries at all.

My hesitation is that I only tested this setup against Watchgoose, so I don't feel comfortable putting my name on examples for services I haven't verified and I am not responsible for. That's why the examples point to Watchgoose, and I think it is only natural and fair, that me putting my work into building it, testing docker-volume-backup with it is doing so that the users would use it alongside Watchgoose.

If it helps, I can make the examples use a placeholder host (e.g. https://monitor.example.com/ping/<uuid>) and keep a single line saying it was tested with Watchgoose. If you'd still rather keep vendors out of the docs, I understand completely, and feel free to do as you feel. Thanks for docker-volume-backup either way, and the offer to donate Watchgoose monitoring services to the project still stands, regardless.

[m90]

If it helps, I can make the examples use a placeholder host (e.g. https://monitor.example.com/ping/) and keep a single line saying it was tested with Watchgoose

This sounds like a good way forward, let's do it like that.

[m90]

and the offer to donate Watchgoose monitoring services to the project still stands, regardless.

Thanks for the offer, by the way, but since there's no running service here, I am delighted that there's nothing to monitor :) I'm sure there's plenty of projects that can make good use of that though.

[bartekrutkowski]

Done: the examples now use monitor.example.com, and there's a line saying the setup was tested with Watchgoose. Let me know if you'd like anything else changed.

Also, let me know if you'd be interested in the donation of free monitoring services, as I've mentioned before, the offer is unconditional (oh, and since you've commented while I was commenting: you can use the donated service to monitor anything, from another project to any private, non-commercial stuff, as long as docker-volume-backup stays Open Source).

[m90]

Thanks, this is now deployed to the docs site.

[bartekrutkowski]

Thanks a lot, I appreciate that! When I'll have a minute, I'll post relevant guide for docker-volume-backup on Watchgoose side. And the donation offer stands, I'm just one message away :)