Docs › Cron inside Docker with RunVouch

Cron inside Docker with RunVouch

Whether you use supercronic, BusyBox crond or ofelia, a scheduled command inside a container has the same two silent failures: the container is not running, or the command ran and produced 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, rv fails open and runs the job unmonitored. Test with docker 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; --log keeps the job's output as evidence.

What RunVouch detects

Need a key? Get a free key · Stuck? contact