Show HN: Dead man's switch without reliance on your infra

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.