Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

So instead of MAILTO=sendmail I use MAILTO=http://deadmandssnitch/report or similar?

That would actually be more stable, since it would rely on a network designed for fault-tolerant redundant store-and-forward messaging.

Instead, each cron job runs an HTTP GET, and later you can view the service's website to see the tests that have requested successfully or haven't responded at all. Unfortunately for your system, if there's a network hiccup, you won't know why your jobs failed and the job will hang on the HTTP call. Also, you're paying for it instead of just sending e-mail alerts to yourself.

Unfortunately for your system, if there's a network hiccup, you won't know why your jobs failed and the job will hang on the HTTP call. Also, you're paying for it instead of just sending e-mail alerts to yourself.

Critically importantly for this use case, if you are doing something critical for your business (say, backups or your daily billing run or sending reminders to thousands of people or what have you) and something goes wrong with your network and makes you unable to curl, you get told about that. If you instead do self-hosted email, and your network fails, you don't get told about that.

It's fail-open vs. fail-close. That's literally so core to the product it is alluded to in the name. A Dead Man's Switch doesn't go off if anything goes wrong, it goes off if everything doesn't go right.

Yes, I understand the concept. But it's actually so open-ended that you get woken up in the middle of the night if something doesn't go right, not everything.

If you have intermittent packet loss on your internet connection you get constant alerts about your backups not working, even though it's just the internet that's wonky. Or if this service isn't set up robustly enough, you miss your alerts when they go down. Either way you get no context about the failure, just obscure panic in the middle of the night. On top of that an attacker can enumerate the URLs (or find it via some other means) and send false requests while they take down your service without you noticing, or the opposite effect with a DDoS on the provider.

I'm not saying it's not a useful service. I'm sure plenty of people would rather pay for this thing and have some peace of mind rather than nothing (because most of these users probably aren't technical enough to do something identical in Google App Engine or a VPS). I just have high expectations for solutions that you have to pay for.

The problem with that setup is that you get alerts that will get lost in the noise. Systems like Nagios, I can set up dependencies, so that I won't get a flood of alerts when the network goes down, or set up maintenance windows so that when I am working on a system, I won't get spurious alerts. Also, self-hosted tools like nagios mean that I can hook it up to send an SMS or use a backup connection, or run a script that triggers an arduino-controlled bat signal to alert me. None of this is really possible with DMS

That's only an argument that there are some cases where DMS is inappropriate, not that it's inappropriate for all cases. Considering that in general, setting up a robust Nagios install, configuring it, and maintaining it, costs far more than DMS, there are many scenarios where DMS is the rational choice.

The biggest problem I see with this service is that exit code 0 does not guarantee the process successfully did what was intended (only that the process ended without errors). This solution seems to leave too many holes for false positives and false negatives to sneak through. When paying for services like this I want it to be bullet-proof rather than bullet-resistant.

Actually something like:

0 6 * * * /bin/sh my_cron_job.sh && curl https://nosnch.in/abc123

Then, when my_cron_job.sh fails (non-0 exit status), no snitch is triggered. DMS notices this hole and notifies you that the job did not run.

Reply on news.ycombinator.com