Sure there is the downside of having to be at your laptop or having it on, but the upside is that it has very few moving parts and is very simple and it just has one set price.
Who cares what you're using, I see show HN posts to be about OP's project, seems like a dick move to me to diverge attention to some other project. I just don't understand the motivation
Personally I love knowing about my competition, and it helps me with how I can differentiate and win over certain niches.
I don't know about OP, but I'm never offended by that, always grateful, helps me craft my message and delivery to the right audience and map out strategy.
I try not to over read into the open internet motivation behind end users, they may become customers, so I rather welcome them and seek to understand rather than judge.
Also, what do you really think the odds are that sigabrt.dev will still exist in 2 years from now? Or 5?
Your service could accomplish something similar if it had such a wrapper to report both success and failures with logs to a remote server. That would take away the need to run a local MTA, while also detecting with the heartbeat whether the job ran at all.
There's currently no explicit "fail" ping, as that's not the main use case I care about. It's valid, though, and I've thought about adding it.
Being able to pipe logs to curl would also be useful. I'm concerned that people might accidentally send me private/sensitive data, but I'll consider it.
It does help. Sometimes jobs unexpectedly don't run at all.
You could also just use systemd timers and do: systemctl --failed -t service
I can see something like this being a great intermediate option to a full monitoring and alerting stack.
I wanted something that required no setup, but could just push success/failure messages to as part of various cron jobs, windows tasks, and shell scripts we run throughout our organization.
StatShed server: https://github.com/statshed/statshed-server StatShed go-cli: https://github.com/statshed/statshed-gocli
The idea is kind of like "ntfy.sh", but for jobs status. You can send a "started" message at the beginning, update a "status" message periodically throughout the job, then send a "failed" message (optionally with logs) or a "success". Then a web dashboard gives you an overview with ability to drill down.
We use Icinga for monitoring and paging, but this just gives an overview for a quick look at things we don't want heavy duty monitoring on. Like my laptop backups, information about ansible runs across our fleet, etc.