Missed runs
Compares what a job promises against what it actually produced. Not "quiet for N days": thresholds are measured in the job's own schedule.
Seen: a driver promising every 3 hours, silent 56 days.Or worse, they return ok: true having done nothing at all. Either way you find out five weeks later, when you go looking for output that was never there. This tells you the same day.
deadman-report.json here to read it.
It is parsed in your browser and never uploaded.
Every rule below came from a real failure that ran unnoticed for weeks. That list is the hard part. You only get it by running a fleet long enough to be burned each of these ways.
Compares what a job promises against what it actually produced. Not "quiet for N days": thresholds are measured in the job's own schedule.
Seen: a driver promising every 3 hours, silent 56 days.Exit code 0, ok: true, zero rows written. The job is fine. The work never happened.
The work ran and the notification didn't. Nobody reads a report that never arrives, and nothing anywhere is marked failed.
Seen: nightly summaries generated fine, delivery 401ing for weeks.Auth silently rejected while the schedule keeps firing on time. This is the one that masquerades as a deliberate pause.
Seen: geocoding 100% down for 51 days on a disabled billing account.The job invokes a script that no longer exists. One stat call, a whole class of silence.
Scheduled months ago, log still zero bytes. There's no cadence to compare against. It has simply never once fired.
Seen: five weekly automations that have produced nothing, ever.On disk, disabled or never loaded. The schedule is irrelevant; it cannot fire at all.
Seen: a retired snapshot job, still installed, silently doing nothing.Still running, but the output is piling up somewhere nobody drains.
Seen: 42 items stuck in one lane for 23 days.A job that stopped is not news. A job that stopped while its siblings kept running is news. The siblings prove the machine, the network and the scheduler are all fine, so the dead one has no excuse.
And a whole project going quiet at once is usually a person deciding to work on something else. Paging you about that is how a monitoring tool teaches you to ignore it. So a deliberate pause gets one grey line, while the same silence with errors underneath it gets your attention. That difference is what turns a 51-day outage into a same-day fix.
On the build server above, that is the difference between 324 red lights and six things worth reading.
A dashboard you have to open is a dashboard you stop opening, and a scan you have to remember to run is one more thing that goes quiet — a funny way for this particular tool to fail. So it sits in the menu bar and says nothing, which is the honest answer almost every day.
A scan takes about 120 milliseconds, so there is no daemon and no cached state. It asks the machine directly, every time. One command installs it:
npx deadmans-switch install-menubar
That installs a plugin for SwiftBar or xbar, reads whichever plugin folder the app is actually watching, and refreshes it. If neither is installed it tells you the one line to run and stops. A signed native app that needs neither is on the way.