stillrunning

Scheduled jobs do not tell you when they stop. That is the whole problem. A crashing job writes a stack trace and somebody sees it, but a job that quietly stops being scheduled writes nothing at all, and nothing is indistinguishable from a quiet week.

stillrunning inverts the check. Every job declares how often it promises to report in, and the alarm is the absence of that report. No agent has to detect its own death, which is the part it is least able to do.

The distinction the market does not make

Dead man's switches for cron jobs are not new. Healthchecks.io, Dead Man's Snitch and Cronitor have all done this for years, and any write-up that pretends otherwise is selling something. What they have in common is that they model three states: it ran, it failed, it is late.

For a job that processes a queue, three is not enough, because the interesting failure is a job that runs perfectly on time and quietly does nothing.

Four of the nine have nowhere to go in the row above, so a monitor built on three states cannot report them even in principle.

So there are nine, and the two that carry the idea are idle, meaning it ran and there was genuinely nothing to do, and quiet, meaning it has succeeded twelve times in a row and done nothing at all. The first is fine. The second is a job that has stopped doing its job while still reporting success every single time. That is the state nobody sells, and it only exists if the job reports what it handled rather than merely that it finished.

Reporting zero is the point rather than an omission. It is what separates an empty queue from a worker that has quietly detached from it.

The board draws absence

Every monitoring tool renders presence as a green lamp, which is the exact collapse this argues with. A lamp gives a dead job and a quiet one the same colour.

The hatched part of the bottom row is the silence. A lamp would have given all four of these the same amount of space.

So each job is a trace, every row ends at the same NOW line, and the gap between the last check-in and now is hatched rather than left blank. Silence is given width. A dead job is a row that visibly does not reach the edge, and you find it by looking rather than by reading.

Tick height carries whether a run did any work, because at three pixels wide a filled mark and a hollow one are the same mark.

Reporting into it

A job checks in with one HTTP call, so anything that can run curl is already compatible. There is a bash wrapper for jobs that run a command, and a dependency-free client for Node and for Workers.

There is also an MCP server, which matters for a specific reason: an exit code says the process finished, not what it did. Only the job knows how many things it handled, and a job driven by a model would rather call a tool than shell out. The wrapper catches the deaths and MCP catches the meaning.

The most useful pattern turned out to be for jobs that cannot be modified at all. A backup process whose runtime is awkward enough that redeploying it to add a monitoring call would risk the backup in order to protect it can still be watched, by treating the arrival of its output in object storage as the check-in. Object created, event rule, HTTP call. Nothing is added to the thing being watched, and the signal becomes better rather than worse: the evidence is now the artifact existing rather than the job's own claim to have produced one. A job that exits zero having written nothing is precisely the failure the whole tool is for.

What it cost to get right

Two bugs nearly shipped, and both were the monitor inventing certainty it did not have. One would have declared a healthy job dead. The other showed a confident green for a job it had never once heard from. I wrote those up in a job that runs on time and does nothing, because the general lesson is more useful than the fix.

The state machine is a single file with no network and no database in it, which is why it can be tested directly, and it is where every argument in the product lives.

Whether it becomes a product

It is running against real jobs and earning its place before any of that gets decided. The honest position is that the dead man's switch itself is a commodity and quiet is the only part worth selling, so a product would have to be built around that rather than around heartbeats.

What would need to be true first: a few weeks of data showing quiet catches something a plain heartbeat misses, and setup that takes minutes rather than an afternoon. If both hold, the shape is a small paid tier for people already running scheduled work who have been bitten once. If neither holds, it stays a tool I use, which is a perfectly good outcome for a thing that already works.