What a dead man’s switch is

A dead man’s switch is a mechanism that acts unless you keep telling it not to.

That is the entire idea. Most machines wait until someone tells them to do something. A dead man’s switch waits for the opposite instruction, repeatedly, and acts once those instructions stop arriving for longer than it was set to allow.

In machinery the allowance is instant: release the handle and the brakes engage. In software it is a period you configure — a day, a week, a month between check-ins — and the switch acts when that period runs out with no check-in in it.

Where the name comes from

The idea comes from machinery, where it existed as a safety mechanism long before it became a software concept.

A train driver’s controller may include a handle that must remain pressed. If the driver lets go — because they are asleep, unwell, or no longer there — the handle rises and the brakes engage.

The same principle appears in chainsaws, lawnmowers, and industrial presses: a control must be actively held, so becoming unable to hold it becomes the signal itself.

The mechanical version usually stops something. The software version usually starts something. That inversion is the only meaningful difference.

What it means for messages

Applied to personal writing, a dead man’s switch addresses a specific problem:

How do you leave words for someone that should reach them only when you are no longer there to deliver those words yourself?

Other approaches leave important dependencies behind.

A letter in a drawer depends on somebody finding it. An email scheduled for a particular date arrives on that date whether you are still around or not. Asking a friend to “give her this if anything happens” depends on that friend remaining reachable, remembering the request, and still being willing to carry it out.

A dead man’s switch replaces those dependencies with one condition:

You stopped checking in.

What it can never tell you

A check-in-based switch cannot tell you that someone has died.

That is the honest limit of this kind of switch, and any service that blurs it is claiming knowledge it does not have.

A check-in-based switch observes exactly one fact: the check-in did not arrive in time.

That silence can have many causes. Someone may have died. They may be in hospital, in prison, on a boat, somewhere without a connection, or simply finished with the service and no longer opening it.

Nothing in a missed check-in distinguishes between those. Inferring death from an absence is not something the mechanism can do, and a service that presents it as death detection is describing something it has not built.

WillSignal states this boundary plainly. A signal going out means one thing: its owner stopped checking in.

What makes one trustworthy

The important question is not whether a dead man’s switch can count down. Counting down is easy.

The important question is what happens around the edges, because the failure that matters most is not a message arriving late. It is a message arriving while its sender is still alive.

Three properties separate a switch you can rely on from an ordinary countdown with a send button.

You have to be able to hear it coming. A switch that goes out silently is a trap. It should reach you before the end, more than once, and its reminders should be timed according to the cycle you chose rather than some arbitrary fixed interval.

It has to fail late, never early. Systems fail. What matters is the direction in which they fail.

If the service is unavailable, a countdown that keeps draining penalizes you for an outage through which you could not have checked in. A trustworthy switch credits that time back. If it cannot confirm that check-ins are working at all, it delivers nothing until it can.

You have to be able to undo it. However careful the safeguards are, some switch somewhere will eventually go out by mistake.

What matters then is whether the mistake is recoverable: whether the sender can pull the message back, and whether the system makes that action readily available at the worst possible moment rather than hiding it behind a support ticket.

How WillSignal’s switch works

WillSignal’s switch is a signal that you keep lit by checking in.

It begins turned off. Nothing counts down, and nothing can be delivered, until you start it yourself. An account that someone creates and then abandons during setup therefore never sends anything to anyone.

Once the signal is running, you choose its cycle: anywhere from one day to thirty days, with three days as the default.

Every check-in restarts the full countdown.

As the signal fades, WillSignal sends reminder emails to the address on your account before your signal goes out. Those reminders are spaced according to the cycle you chose. Each one tells you how much time remains and asks you to check in.

They never identify a message or a receiver.

If the countdown reaches zero, the signal goes out and the messages you have ready are delivered inside the app to the receivers who have joined WillSignal by then, up to your delivery slots.

Anyone you addressed who has not joined yet, and anyone beyond your slots, waits for a later time rather than being missed — nothing is lost, and nothing is exposed. The FAQ explains how the slots work.

Message content is never emailed or sent by text. No email from WillSignal ever carries your words.

The safeguards on the other side then become available.

Any delivered message can be pulled back. Pulling it back removes it from the receiver’s inbox, although it cannot undo anything the receiver has already opened and seen.

Restarting after a mistaken delivery carries a lock: one month, growing to three and then six if it keeps happening. The lock is measured from the moment your signal went out, not from when you restart. It exists so that a signal going out continues to mean what it says.

Every other fail-safe leans in the same direction.

Running countdowns are credited forward through an outage. WillSignal also watches its own check-in path, and while that watch cannot confirm the path is healthy the service is set to hold delivery rather than let it proceed.

A failure on our side can postpone delivery. Nothing here is built to start one.

What it is not a substitute for

A dead man’s switch is a delivery mechanism for words. It is not a legal instrument, and it should not be the only place where anything urgent is stored.

Anything that must happen quickly — including medical wishes, account access, or care instructions — should never exist only behind a countdown. How slow that countdown is depends on the service and on the cycle you set; WillSignal’s is deliberately unhurried, and its shortest exposed cycle is a full day.

A will that disposes of property is also a legal document with formal requirements. Writing text into an application’s database does not satisfy those requirements.

The two do different jobs. A will decides who receives what, and it has to be made in the form the law where you live requires. WillSignal holds the words you want a particular person to read, and claims no legal effect for them.