Dead man's switch monitoring

A Dead Man's Switch for Jobs, Workers and Applications

A dead man's switch monitoring pattern treats expected evidence of life as meaningful. Silence becomes a condition to investigate.

The core idea

A scheduled job, worker or remote application is expected to report on a known cadence. The report is not a full health assessment. It is evidence that the process reached a particular point and could make its outbound request.

If the expected evidence does not arrive, the system around it can begin an investigation. That is why the pattern is useful for cron jobs, backups, imports, synchronization and background workers.

What the pattern can and cannot prove

A heartbeat can show that code ran far enough to send a report. It does not prove that every downstream record is correct, that a backup can be restored, or that the whole service is ready for user traffic. Pair it with logs, metrics, validation and restore tests where those questions matter.

HeartbeatHook's role

HeartbeatHook provides the authenticated application endpoint and the signal relay around it. It records incoming application requests and supports authenticated pending-signal reads and ACKs. It does not currently claim to generate alert notifications, inspect backup contents or replace an incident management system.

Good placement for a report

  • after a job has completed its meaningful work;
  • after a worker has reached a safe checkpoint;
  • after a synchronization step has committed its own state;
  • after a backup command has finished, while keeping restore validation separate.