I wrote this Go project to implement a dead man’s switch that didn’t rely on cron jobs, timers, databases, etc on the infra it runs on. Deadcheck integrates to PagerDuty and keeps a long running incident snoozed until expected check-in times where it’ll alert unless a check-in occurs.
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".<p>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".<p>This is a watchdog timer / monitor / heartbeat, setting off an alert if a timer elapses.
I guess I'm an oldster shaking my fist at clouds, but ...<p>Depending on where you live, and if it matters, give it to an attorney.<p>Maybe use this to trigger the notification to your attorney, with instructions on how to double check things before doing things.
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?<p>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.
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 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.<p>We called it a dead man's switch but it was really just a way to monitor alertmanager.
Speaking of not using anyone’s specific infra, we deployed software on blockchains to do this.<p>We had to implement a “heartbeat” and “succession” in our blockchain-based solutions for organizations to control things together.<p>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.<p>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.<p>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)<p>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.<p>Here is more info on the why:
<a href="https://community.intercoin.app/t/intercoin-applications-control-and-multisignature/2898" rel="nofollow">https://community.intercoin.app/t/intercoin-applications-con...</a><p>And here are the rest of the blockchain apps for organizations:
<a href="https://community.intercoin.app/t/applications-of-intercoin-making-crypto-mainstream/87" rel="nofollow">https://community.intercoin.app/t/applications-of-intercoin-...</a><p>You can go ahead and use it, the factory it’s been deployed on many EVM blockchains, at the same address.<p>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.
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?<p>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)
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.
The problem with these kind of project is that they are no good for very serious situations. Say Navalny set it up. They kidnap someone, the make you delete the pagerduty service and then kill you. Immutable / undeletable tasks would be needed.
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.
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.
Cool trick using PagerDuty like that.<p>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.