What is heartbeat monitoring (a dead man's switch)?

What it is, in plain words

Some trains have a pedal the driver must keep pressing. If the driver lets go, because they fell asleep or were taken ill, the train brakes on its own. That is a dead man’s switch: it acts on the absence of a signal, not on an alarm.

Heartbeat monitoring is the same idea for software. The automation is expected to show a sign of life on a schedule: a check-in message, a new row, a published post, a line in a log. A separate checker knows when that sign is due. If it has not appeared by then, the checker alerts a person.

The point is what it catches. Most alerts depend on the automation noticing its own failure and reporting it. A job that never started cannot report anything. Neither can one that was killed by a restart or is waiting on a computer that went to sleep. Silence is the failure, and only something outside the job can hear silence.

A concrete example

I run a scheduled publishing job with several slots a day. Next to it runs what I call a watchdog: every morning at 08 it checks whether each slot actually ran after its most recent scheduled time, and it messages me only when something looks wrong. It stays quiet on good days on purpose. A check that reports “all fine” every morning soon stops being read.

It has caught real misses. One morning a slot had not run because a scheduled job that was supposed to switch it back on ran after the slot time, not before. The watchdog flagged “no run since the scheduled time”. It could not save that slot, but it meant I knew the same morning instead of days later.

It has also missed things, and those misses taught me more:

• It failed together with the thing it watched. One night, a system update restarted the computer three times after 1 a.m. The machine stayed on, but nobody was logged in, and the jobs were set to run only for a logged-in user. Three overnight slots did not run, and neither did the 08 watchdog, because it had the same setting. No alert at all. The rule I wrote down afterwards: the watchdog has to stand on a different failure mode from the job it watches.
• It checked that the job ran, not that it worked. For two days a login token was refused and five slots in a row published nothing, while every run started on time. The watchdog saw five runs and stayed quiet (the full incident). It now also checks the login directly every morning.
• Its first version raised false alarms. Once because a single lookup failed briefly, and once because it read a text message it could not parse properly. It now retries three times before reporting, and counts the prepared items directly instead of reading text.

My website publishing jobs add one more habit: they check their login on every run, even on days with nothing to publish, so an expired token is reported days before a scheduled post would run into it.

Why it matters when you hire someone

A freelancer’s demo shows the automation working. It cannot show what happens on the night it does not run. Without a heartbeat check, the first person to notice a silent stop is usually you, days later, looking for a report that never came. The acceptance checklist for unattended automations tests for exactly this.

Three details decide whether a heartbeat check is worth having:

1. It looks at the result, not the attempt. “The report is in the folder” beats “the job started”.
2. It runs somewhere else, or at least under different settings, so a restart, a sleeping machine or an expired login does not silence both.
3. It reaches you, not only the freelancer, and only when action is needed.

A computer that goes to sleep is a common cause of silent stops, and a heartbeat check is how you find out. The field note on scheduled jobs and sleep mode shows how quiet that kind of failure looks.

What to ask the freelancer

Add these to the “Failure behaviour” field of the workflow automation brief:

A good answer names the result it looks for, the time it looks, where it runs and who it tells. “You’ll get an email if there’s an error” is not an answer to question 1.