DEV Community: benjamin

I built a local dead-man's-switch for cron jobs (no server, no signup)

benjamin — Tue, 09 Jun 2026 16:08:39 +0000

Cron has a cruel design flaw: it tells you nothing when a job stops running.

A job that exits non-zero? Silent. A job that never fires because the host was
asleep? Silent. A backup script that's been dying at 2 a.m. for three days
straight? Completely silent — right up until the morning you actually need that
backup and discover the last good copy is from Tuesday.

The failure mode isn't "the job errored." It's the absence of success, and
absence is exactly the thing a logs-and-exit-codes mental model can't catch.

The usual fix, and why it bugged me

The classic answer is a heartbeat monitor: your job pings a URL when it finishes,
and a watchdog yells if the ping doesn't arrive on time. healthchecks.io,
Cronitor, Dead Man's Snitch — all good, all battle-tested.

But for a box of personal cron jobs and a few self-hosted boxes, they felt like
overkill:

I had to create an account.
My job names and timing metadata went to a third party.
It was one more SaaS dashboard to log into and forget about.

I wanted the heartbeat idea without the hosted part. So I built deadcron —
a single CLI, zero dependencies, no server, no signup. State lives in a JSON file
under ~/.deadcron. Nothing leaves your machine unless you explicitly point it at
a webhook or SMTP server.

How it works

Three moving parts:

Each run checks in. Wrap your command and deadcron records a "ping" on exit 0 (and the exit code on failure):

   # before:
   0 2 * * *  /opt/backup.sh

   # after:
   0 2 * * *  deadcron run backup --every 1d --grace 1h -- /opt/backup.sh

A job declares its expected rhythm with --every (plus an optional
--grace). If the time since the last successful check-in exceeds
every + grace, the job is overdue.
A watchdog runs check on its own schedule. You add it to cron once:

   deadcron install --every 5m

That's it. Now if backup doesn't succeed within a day (+1h slack), the next
check tick notices the silence and alerts you.

$ deadcron status
● backup    ok                every 1d   last: 3h ago
● sync      OVERDUE by 2h     every 1h   last: 5h ago
● report    FAILED (exit 1)   every 1w   last: 2d ago

check exits non-zero when anything is overdue or failed, so it also drops
straight into CI or any other scheduler:

deadcron check            # exit 1 if unhealthy
deadcron check --json     # machine-readable

Alerts, but only where you want them

check fires every channel you've turned on — and they all run locally:

deadcron config enable macos                 # native notification
deadcron config set-webhook https://hooks.slack.com/services/XXX
deadcron config set-email --to me@you.com --sendmail
deadcron config test                         # send a sample through all of them

Channel	How
terminal	writes to stderr (great for CI / piping)
macOS	native banner via `osascript`
webhook	`POST` JSON `{event, checkedAt, jobs}` → Slack/Discord/your endpoint
email	local `sendmail`, or direct SMTP (TLS 465 / STARTTLS, optional auth)

Repeat alerts are throttled (default: once per hour per job) so a long outage
doesn't turn into a notification flood.

Install

It ships on both registries, because half my cron jobs are Node and half are
Python:

npx deadcron            # Node — zero deps
pip install deadcron    # Python — pure stdlib

Both implementations share the exact same ~/.deadcron state format, so you can
mix them on one machine and they won't step on each other.

A few design notes

No daemon. deadcron isn't a long-running process — it's just a CLI plus a state file. The "watchdog" is literally deadcron check invoked by your own cron. Less to crash, less to babysit.
run over ping. You can call deadcron ping <name> at the end of a script, but wrapping with run also captures non-zero exit codes, so a job that fires on time but crashes is still flagged.
grace matters. A job that runs "every hour" never runs at exactly one hour. Grace is the slack that keeps borderline timing from crying wolf.

Try it / break it

Code, issues, and the full README:

Node: https://github.com/jjdoor/deadcron
Python: https://github.com/jjdoor/deadcron-py

It's MIT, it's tiny, and I'd genuinely like to know where it falls over. If
you've got a cron job you'd be sad to lose silently, point deadcron at it and
tell me what's missing.

What do you use today to know your scheduled jobs are actually running?

I built a 1-file CLI to catch .env drift before it causes production bugs

benjamin — Tue, 09 Jun 2026 15:00:48 +0000

Almost every developer has fought .env issues. They're silent, annoying, and they only show up after you deploy or after someone clones the repo.

Here's the exact failure I hit one too many times:

I add STRIPE_KEY to my local .env.
I ship code that reads process.env.STRIPE_KEY.
I forget to add STRIPE_KEY to the committed .env.example.
A teammate clones, runs the app, and it crashes on a missing variable.

The reverse is just as common: .env.example promises a key you never actually set locally — a silent misconfig waiting to bite.

The two files are supposed to declare the same set of keys. They drift apart constantly. So I built a small guardrail.

dotdrift

Zero dependencies, one command:

npx dotdrift

x drift detected between .env and .env.example

  Missing in .env.example (add these so teammates know they're needed):
    + STRIPE_KEY

  Tip: run "dotdrift sync" to update .env.example automatically.

It exits non-zero on drift, so it drops straight into CI:

- run: npx dotdrift --strict   # --strict also flags empty values

The part I actually wanted: `sync`

Detecting drift is half the problem. The annoying half is fixing the template by hand. So sync regenerates .env.example from your real .env:

npx dotdrift sync

values are stripped (KEY=),
your comments and blank-line grouping are preserved,
curated placeholders already in the template survive (a hand-written PORT=3000 stays),
it's idempotent — run it twice, nothing changes.

So updating the template is now one command instead of a manual chore.

Make it permanent

npx dotdrift hook

Installs a .git/hooks/pre-commit that blocks commits when things drift. A one-time tool becomes a continuous safety net.

Monorepo

npx dotdrift -r

Scans every subdirectory that has an .env/.env.example pair (skips node_modules, dist, etc.) and reports per service.

Notes

Zero dependencies — Node stdlib only, ~250 lines.
It only ever compares key names (and, with --strict, whether a value is empty). It never prints or transmits your secret values.
Understands KEY=value, export KEY=value, single/double quotes, KEY= (empty), # comments, and inline comments on unquoted values.
MIT licensed.

Repo: https://github.com/jjdoor/dotdrift
npm: npx dotdrift

If you hit a parsing edge case or the sync output isn't what you'd expect, open an issue — that's exactly the feedback I'm after.