The map · Part Two · The machine · Chapter 18 of 23
The dead man's switch
A crashed run and a run with nothing to say used to look identical: both were silence. Now one observer shouts when something breaks on the machine, and another alarms on the absence of a signal, which is the only alarm a dead machine can still raise. About 9 minutes · on the 10-minute route.
Here is the failure that the whole of this chapter exists to remove. The nightly run sends a message to the owner's phone only when a name needs attention. Most nights, no name does, and the phone is quiet. Now suppose the run crashed at 22:30 on a Tuesday and has been dead ever since. The phone is quiet. The two situations, "nothing needs you" and "nothing has run for a week", produce exactly the same experience: silence. In the tool's own words, "a monitor whose failure mode is silence is a monitor that stops being believed the first time you find out the hard way."11vss/heartbeat.py, opening.
The name, and where it comes from
Trains have a handle the driver must hold or press at intervals. If the driver collapses, the handle is released and the brakes apply. It is called a dead man's handle, and the design idea is that safety must not depend on a signal being sent, because a person who cannot send it is exactly the case it exists for. It must depend on a signal that keeps arriving, with the alarm on its absence.22Wikipedia, Dead man's switch: 'Vigilance control was developed to detect this condition by requiring that the dead man's device be released momentarily and re-applied at timed intervals.' The software version is called a dead man's switch, and it works the same way: something expects a regular signal, and raises the alarm when the signal does not come.
Two observers, because there are two kinds of dead
A machine can be alive and broken, or it can be dead. These need different observers, because an observer that lives on the machine dies with it.
Observer one lives on the machine
When the run fails, the scheduler starts the notifier from chapter 17, which pushes to the phone what stopped and the last lines of the log. This is the fast observer: it fires while the failure is happening, and it can describe it. Its weakness is that it needs the machine to be up, the scheduler to be running, and the timer to have fired. A timer that was disabled after a reboot starts nothing, so nothing fails, so nothing shouts, and that is precisely the failure that looks most like a quiet week.
So observer one has a second leg on its own timer: every morning at 09:30, a separate job checks whether a completed run is on record and whether the nightly timer is still enabled. It runs on its own timer deliberately: "if the check on the run shared a timer with the run, the failure that stopped the run would stop the check, and the switch would be wired to its own power supply."33deploy/vss-checkin.timer, comment. The run also records its own completion in a table, with a bar of 72 hours for the nightly and 10 days for the weekly, and a test run or a single-name run does not reset the clock.
Observer two lives outside
None of that helps if the machine is off, the network is down, or the whole scheduler is stopped. A dead machine cannot page itself. The only thing that can notice a dead machine is something that is not on it: an outside service that expects one signal a day and raises an alarm when the signal does not arrive by a deadline.44vss/heartbeat.py: 'a dead VPS cannot page itself... Closing that needs an OUTSIDE observer — a service that expects a ping and alerts on its ABSENCE.' That is the empty request from chapter 17's success exit. The outside service "keeps silent as long as pings arrive on time" and "raises an alert as soon as a ping does not arrive on time", with a grace period after the expected time.55The monitoring service's own documentation; the suggested settings in the example environment file are a one-day period and a six-hour grace.
Why absence beats error
An error message needs a sender. Every sender can fail in a way that prevents sending: the process crashed before reaching that line, the network was down, the machine was off. An alarm on absence needs nothing from the failing side. It is the only kind of alarm whose coverage includes the case where the thing being watched no longer exists. That is why the successful run makes a sound to the outside observer and no sound to the phone: the sound is not for the owner, it is for the thing that will notice when the sound stops.
The owner's words when this leg was added: "a dead VPS is exactly the case I want covered and no ping leaves data."66deploy/vss-ping-healthcheck.sh, quoting the owner, 2026-09-01.
Why the notification address stays out of the repository
The phone notifications go through a public push service where anyone who knows a topic's name can post to it. The topic name is therefore the only secret the service has, and it lives in a file in the owner's home directory that is never committed. The program reads it from the environment first, then from that file, and never writes, logs or prints it. The same file holds the outside observer's address. The repository contains an example file with both left blank.77deploy/vss.env.example: 'THE REAL FILE IS NEVER COMMITTED: the topic is the only secret ntfy has.' vss/env.py reads the environment first, then the file. The topic is outbound only: nothing in the project ever reads from it, so even a leaked name lets an outsider post noise to the owner's phone, not read anything.
What is not covered, said rather than implied
- The weekly screen has no outside signal of its own. A dead weekly screen is caught only by the morning check-in.
- A machine that is up, pinging, and wrong. The outside observer proves the run finished, not that it was right.
- The outside observer itself being down.
- The phone tunnel (chapter 19) has no failure notification, for a reason that chapter explains.
A defect the design found in itself
On 2026-09-13 the page server restarted seven times in a row because of a missing directory, and the notifier sent seven messages. Each one said that no report had been written for the day, because that sentence had been written for the nightly run and reused for every unit. For a page server that never writes a report, the sentence was false. The fix, recorded as a backlog item and committed the same day, gives each unit its own accurate sentence about what its stopping means.88Backlog item B-13; commit 'the failure notifier says what stopped, not "no report was written" for every unit'. A notifier that lies, even slightly, is on its way to being ignored.
- Decided
- Two observers. One on the machine that describes what broke; one outside that alarms on the absence of a daily signal. The success exit signals the outside observer and says nothing to the phone.
- Why
- Silence has to mean one thing. The only alarm that covers a dead machine is one raised by something that is not on it.
- Cost
- A second external service, whose own outage is uncovered. A signal that leaves the machine every night, kept to one empty request so that nothing about the book leaves with it.
Sources for this chapter
- Dead man's switch, Wikipedia
https://en.wikipedia.org/wiki/Dead_man%27s_switch - Healthchecks.io documentation (alarm on a missing ping)
https://healthchecks.io/docs/ - The heartbeat module and the units — read from this repository: vss/heartbeat.py; deploy/vss-checkin.timer; deploy/vss-ping-healthcheck.sh; deploy/vss-notify-failure.sh; deploy/vss.env.example; reference/BACKLOG.md B-13
The slow way, made survivable. Built 2026-09-13 from the repository as it stood that day. NAME A and NAME B are fictional; no company, price or holding appears on this site. Not financial advice: one private investor's method, shared as it is.