Run it yourself

MIT licensed, one server file, one client file and a SQLite database. No external service is required to run it, and the hosted version and the self-hosted one are the same code.

Five commands

git clone https://github.com/runvouch/runvouch && cd runvouch
python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
cp .env.example .env          # nothing in it is required to boot
.venv/bin/uvicorn runvouch.server:app --host 127.0.0.1 --port 8787
curl localhost:8787/health

That is a working install. The database creates itself on first start under data/, every setting has a default, and the detectors begin sweeping straight away. Put it behind nginx or a tunnel when you want it reachable, and set RUNVOUCH_PUBLIC_URL so the proof files point at the right host.

What runs where

The server is runvouch/server.py: the API, the detectors, the alert delivery, the proof chain and the dashboard, in one file on FastAPI and SQLite. Two dependencies, pinned.

The client is runvouch/cli.py: standard library only, no dependencies, ever. Copy that one file onto a machine and rv run works. It also fails open, so a monitoring outage can never take down the job it watches.

The proof rules are runvouch/proof.py, and templates/verify_proof.py repeats them on purpose so a reader can check a run without importing anything of ours.

Nothing calls home. Alerts go where you point them: e-mail through your own Resend key, Telegram, Slack, a webhook, or nowhere at all.

What you give up, honestly

The Bitcoin anchor needs one more package. The hash chain works out of the box; anchoring the daily root with OpenTimestamps needs the ots client installed. Without it the chain still seals and still verifies, it just has no third party attesting to the date.

Alerting needs a channel. Self-hosted with no Resend key and no Telegram token means the detectors fire and nobody hears it. Set one before you rely on it.

You are the uptime. A watchdog on the same machine as the jobs it watches shares their fate. That is fine for a homelab and wrong for anything that matters: run it somewhere else, or let us run it.

When Healthchecks.io is the better answer

If what you need is "tell me when cron did not fire", Healthchecks.io has done exactly that since 2015, it is open source, it is excellent, and it has eleven years of people finding its edge cases. Use it. We would rather say that here than have you find out in a month.

Where this one differs is what it does after the job checks in: evidence that the work actually happened, cost and duration drift against the job's own baseline, retry storms, and a per-run record that cannot be edited afterwards. The full comparison, including where they win: vs Healthchecks.io.

Tests are part of the deal

The suite is 99 tests and runs in under half a minute with no network. If you fork this, that suite is how you know your change did not break a detector.

.venv/bin/pip install -r requirements-dev.txt
.venv/bin/python -m pytest -q tests

The hosted version

Same code, and free for 20 agents with every detector on. The reason to use it is that somebody else is awake when your machine is not: get a free key. Moving between the two is a change of one environment variable, because the client only knows a URL and a key.

MIT. Source on GitHub. Issues and pull requests are read by a person.