Show HN: Dead man's switch without reliance on your infra
A new open source tool uses PagerDuty’s alerting features to act as a “dead man’s switch” for cron jobs and other scheduled tasks, triggering incidents when expected heartbeats or check-ins don’t arrive. Commenters compare it to existing heartbeat and uptime monitors, debate whether this kind of configuration belongs in Terraform or a separate service, and weigh the tradeoffs of relying on third‑party SaaS versus running monitoring on one’s own infrastructure. The conversation also touches on broader use cases, from monitoring alerting systems themselves to handling actions after a person’s death or incapacitation.
Project behavior and purpose
- Tool configures heartbeat-based checks in external alerting systems (currently PagerDuty).
- Jobs/services “check in” at expected times; missed check-ins cause alerts regardless of the monitored infra’s state.
- Unlike simple intervals, supports arbitrary schedules (e.g., specific times on weekdays) and time-window deltas.
- Runs as a self-hosted service that only calculates and updates snooze/heartbeat configurations; the actual alerting is done by the vendor.
Comparison to other tools and IaC
- Some suggest this logic could live in Terraform or use existing Terraform providers (e.g., for PagerDuty).
- Compared to services like Cronitor, BetterStack, Checkly, OpsGenie, etc., this is positioned as:
- “Missing heartbeat → alert” wiring specifically into PagerDuty.
- More expressive scheduling than some interval-only heartbeat monitors.
- Question raised: if you already depend on SaaS (PagerDuty), why not use a SaaS that directly hosts heartbeat endpoints?
Infra, reliability, and dependencies
- Supporters argue: monitoring should not rely solely on your own infra; using a robust external provider increases fault tolerance.
- Counterpoint: dead-man switches feel too important to rely on third-party services you don’t control.
- Retort: everything ultimately depends on someone else’s infra (power, ISP, cloud); prepaying a cloud service is often simpler and more reliable.
- Some already use multi-region Alertmanager, OpsGenie, or similar to monitor the monitors.
Naming and concept (“dead man’s switch” vs heartbeat)
- Several note this is essentially a watchdog/heartbeat/cron-job monitor, not a literal “dead man’s switch.”
- Others argue the definition fits: if the operator/system fails to act (send heartbeat), an automatic action (alert) triggers.
Use cases beyond infra & after-death actions
- Thread veers into “what happens after I die”:
- Interest in digital estate handling, debt/estate law nuances, and ensuring survivors can access assets.
- Ideas include “death README” documents, attorneys as executors, or specialized “dead man service” companies.
- Concerns about robustness (e.g., hospitalization, coercion scenarios, immutable tasks).
Integrations and future directions
- Interest in adding more alerting vendors (Squadcast, telco systems, messaging apps with “send later,” blockchain-based control contracts).
- Project maintainer open to contributions and treating core logic as a library.