If you call this a "dead man's switch" I'd expect it to turn my app off when I die. E.g. "switch" something when something happens to a "man".

Your own README links to this definition: "A dead man's switch is a switch that is designed to be activated or deactivated if the human operator becomes incapacitated".

This is a watchdog timer / monitor / heartbeat, setting off an alert if a timer elapses.

The term of art you're looking for is: "heartbeat check"/"healthcheck", or most commonly: "cron job monitor".

I guess I'm an oldster shaking my fist at clouds, but ...

Depending on where you live, and if it matters, give it to an attorney.

Maybe use this to trigger the notification to your attorney, with instructions on how to double check things before doing things.

I sometimes think about a “dead man service”: you leave instructions (that you upload to the service), then when you pass away/etc, the service operators go and follow your instructions and do whatever you asked for. You’d pay some pre-agreed sum, possibly annuity-type subscription, and at the end we go and follow your wishes. Basically a technically competent will executor. It’s probably too much to expect your family to know how to operate your systems. Maybe you encrypt the instructions and give fractional keys to family etc.

I’m not sure I understand what the application itself does; as far as I can see, it basically configures the external services to carry out the actual checks and ensures this configuration is up to date?

Wouldn’t it be better to do this as part of a Terraform script or something? Not to take away from the project, it sure looks neat—just wondering if I really want to deploy yet another, independent IaC tool.

So... like BetterStack's heartbeat monitor? [0]

[0] https://betterstack.com/docs/uptime/cron-and-heartbeat-monit...

I did something similar years ago when I was working with observability. Prometheus alertmanager triggers a special alert constantly that calls a lambda (or any webhook), so when alertmanager dies or is unable to alert then the lambda will send an alert over a 3rd party push service to notify ops that alertmanager is down.

We called it a dead man's switch but it was really just a way to monitor alertmanager.

Better have something that runs off the cloud. PagerDuty is not something under your countrol. A stuff as imporant as dead man switch should not rely on someone's service.

A possible integration are messaging apps that support send later. I sometimes set these up if I'm going hiking.

I feel like posting a software project to HN and meeting criticism is some near-end-stage of programming mastery.

I'm not sure running an additional service plus a SaaS requirement is better than relying on infra. Standing up this service is going to rely on your infra. What if it goes down?

If you're going to have to write a scheduled check-in anyways, why not use something like cronitor and reduce the complexity? (they host the check-in endpoint)

Nice one! Do you have any plans to support something else apart from Pager duty. I have been using Squadcast.com for my hobby project monitoring. Integration with that would be nice. I'm open to create a PR if you are interested.

Neat. We use OpsGenie to monitor our alerting infra and it has deadman/heartbeat support so something like that is another way to go.

Cool trick using PagerDuty like that.

If you don’t want to use a service like Cronitor, you can self-host this without the usual fear that an outage will also take down your monitoring.

Any support for something besides pager duty? I work for a telco and there are so many different heartbeats we rely, this project seems very useful for something like that. The config file looks much better than the python/perl/bash whatever scripts we have scheduled on our systems.

Very clever. I have Alertmanager in a second region so it can check on my first Alertmanager, but this is much nicer.

I’ll use this for my next wormable vuln instead of hard coding DNS checks ;)

I don't know about the rest of the people here, but I aim to outlive PagerDuty.

Do the people on the receiving end of a pagerduty notification require pagerduty accounts?

I don't understand this. You're still taking on a dependency on some infra, but now that infra is Pagerduty. What problem is this even solving

Not to be confused with deadmanssnitch.com

Speaking of not using anyone’s specific infra, we deployed software on blockchains to do this.

We had to implement a “heartbeat” and “succession” in our blockchain-based solutions for organizations to control things together.

It’s part of our “application suite for organizations” where each one is sort of this general-purpose LEGO block that could be used to build a custom solution.

In each case, you’d enter some parameters and create an instance from a Factory. We made it simple and secure for any organization to use this.

In this specific one, ControlFactory is used to create ControlContract instance that can be used to control an address together (to sign off things collectively, like transfer tokens or call an arbitrary method on a different address)

We had to handle what happens if the M of N people don’t show up for a while. And we said they have to call a heartbeat() method every so often. If they fail to call it then control temporarily passes to the next group in succession, until the OGs can finally call the heartbeat() method again.

Here is more info on the why: https://community.intercoin.app/t/intercoin-applications-con...

And here are the rest of the blockchain apps for organizations: https://community.intercoin.app/t/applications-of-intercoin-...

You can go ahead and use it, the factory it’s been deployed on many EVM blockchains, at the same address.

PS: fun fact, you can configure a ControlContract to also manage calling methods on itself, thereby creating custom “policies” for organizations when it comes to granting/recoving rights of other people to the quorum.