Docs › Cron in Docker monitoring with RunVouch
Cron in Docker monitoring with RunVouch
Cron in Docker monitoring for the two failures every container cron shares: whether you use supercronic, BusyBox crond or ofelia, a scheduled command inside a container either does not run because the container is not running, or runs and produces nothing.
How it runs on Cron inside Docker (supercronic, crond)
The crontab line (or the ofelia label). Install runvouch in the image; rv has no dependencies beyond Python 3.
Store the key
Pass the key as an environment variable (-e RUNVOUCH_KEY, env_file: in Compose, or a Docker secret read at start).
Wrap the job
# crontab used by supercronic
0 2 * * * rv run nightly-report --evidence-file /out/report.html -- python /app/report.py
# docker-compose.yml
services:
cron:
image: ghcr.io/you/report:latest
command: supercronic /app/crontab
env_file: .env # contains RUNVOUCH_KEY=rv_...
volumes: ["./out:/out"]rv fails open: if RunVouch is unreachable the job still runs and you get one warning line.
Register the cadence and caps
rv agent nightly-report --cadence 24h --grace 30m --max-runtime 1h --evidence --cap-run-cost 2
Register the agent once, from anywhere with the key. Cadence is what turns a schedule that stopped into an alert; --evidence makes a run without evidence a failure; the caps pause the agent when it overspends.
What goes silent on Cron inside Docker (supercronic, crond)
- BusyBox crond inside a container does not load the container's environment for the job by default; if the job cannot see
RUNVOUCH_KEY,rvfails open and runs the job unmonitored. Test withdocker exec ... rv status. - A container restart loop means no cron ticks; MISSED after cadence plus grace.
- Logs go to the cron daemon's stdout at best;
--logkeeps the job's output as evidence.
What Cron inside Docker (supercronic, crond) does not tell you
A cron daemon inside a container writes to its own stdout at best (supercronic) or to nowhere (BusyBox crond without -f -l). Docker reports container health only if a HEALTHCHECK is defined, and a healthy cron container is one where the daemon process exists, not one where the jobs ran. A restart loop, a wrong timezone in the image, or a job that cannot see its environment variables produces no signal outside docker logs.
What RunVouch detects
| Alert | What it means here |
|---|---|
| MISSED | cadence plus grace passed and no run started |
| FAILED | non-zero exit or a reported failure, with the stderr excerpt |
| NO_EVIDENCE | the run said ok but the file, URL or assertion you required is missing |
| STALLED | a run started and never ended within max runtime |
| RETRY_STORM | the same tool called with identical input many times in one run |
| BUDGET_RUN / BUDGET_DAY | cost cap crossed; the agent is paused until you resume it |
| DRIFT | duration or output size far off its 7-run baseline |
Set up in two minutes
- Get a free key (3 agents, no card) and store it where this page says.
- wrap the job: copy the snippet above into the scheduled job.
- Register the cadence once:
rv agent nightly-report --cadence 24h --grace 30m --evidence, or let the first run create the agent and set the cadence on the dashboard. - Send one test alert:
curl -X POST https://api.runvouch.com/v1/settings/test-alert -H "X-API-Key: $RUNVOUCH_KEY". The next missed, failed or empty run reaches the same channels.
Also running platforms?
Render Cron Jobs. Railway cron schedules. Fly.io scheduled Machines. The full list of runtimes is on integrations, and the same agent can report from several of them: one job, one cadence, wherever it happens to run.
Need a key? Get a free key · Stuck? contact