Docs › Fly.io scheduled Machine monitoring with RunVouch
Fly.io scheduled Machine monitoring with RunVouch
Fly.io scheduled Machine monitoring from outside the Machine: on Fly you either run a Machine with a schedule (fly machine run --schedule daily) or run cron (often supercronic) inside a long-lived Machine. Both stop when the Machine is destroyed, stuck or out of memory, and neither tells you.
How it runs on Fly.io scheduled Machines
The Machine's command, or the crontab line inside the container. The image needs Python 3 for rv.
Store the key
fly secrets set RUNVOUCH_KEY=rv_...; secrets are exposed as environment variables in every Machine of the app.
Wrap the job
# scheduled Machine (runs once per schedule, then stops) fly machine run ghcr.io/you/report:latest --schedule daily \ --command "rv run nightly-report --log /tmp/report.log -- python report.py" # or, inside a long-lived Machine with supercronic 0 2 * * * rv run nightly-report --evidence-file /data/report.html -- python /app/report.py
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 Fly.io scheduled Machines
- Scheduled Machines run "approximately" at the interval; use a grace of an hour or more.
- An OOM-killed Machine restarts (or does not); the run that was in flight never ends and becomes STALLED.
- A Machine that was stopped by
fly scale count 0or a failed deploy takes the cron with it; MISSED is the signal.
What Fly.io scheduled Machines does not tell you
Fly documents that scheduled Machines are started approximately on the schedule and that Fly does not run a cron service; the schedule is a Machine property that stops existing with the Machine. There is no notification for a Machine that failed to start, was OOM-killed mid-run, or was scaled to zero. fly logs is the only record and only for as long as the log retention.
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?
Cron inside Docker (supercronic, crond). Render Cron Jobs. Railway cron schedules. 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