Docs › RQ Scheduler monitoring with RunVouch
RQ Scheduler monitoring with RunVouch
RQ Scheduler monitoring for the two processes it needs: scheduler.cron("0 2 * * *", func=nightly_report) stores the schedule in Redis; the rqscheduler process moves it into a queue on time; an rq worker executes it. A supervisor that restarts the worker but forgot the scheduler is the usual way it stops.
How it runs on RQ Scheduler
Inside the job function with the Python client, so the run starts when a worker actually picks the job up. Register the agent's cadence once.
Store the key
RUNVOUCH_KEY in the rq worker's environment; the scheduler process does not need it.
Wrap the job
# schedule.py (run once; use_local_timezone=False means UTC)
from redis import Redis
from rq_scheduler import Scheduler
from jobs import nightly_report
scheduler = Scheduler(queue_name="reports", connection=Redis("redis"))
scheduler.cron("0 2 * * *", func=nightly_report, queue_name="reports", id="nightly-report", use_local_timezone=False)
# jobs.py
import runvouch
def nightly_report():
with runvouch.vouch("nightly-report", source="rq", evidence=lambda: {"rows_written": n > 0}) as run:
n = build_report()
run.tool("llm.summarise", {"rows": n}, cost=0.03)
# processes (both must be running): rqscheduler --url redis://redis:6379 | rq worker reports
# rv agent nightly-report --cadence 24h --grace 30m --evidencerv 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 RQ Scheduler
- No
rqschedulerprocess: the cron entry stays in Redis and is never enqueued. Norq workeron the queue: it is enqueued and never runs. Both are MISSED. - rq-scheduler does not catch up on ticks it missed while it was down.
- A failed job lands in the FailedJobRegistry with its traceback; RQ does not retry unless
Retry()was passed, and it sends nothing anywhere. - Jobs that exceed the RQ job timeout (default 180 s) are killed with a
JobTimeoutException; set the agent's max runtime to the same value so STALLED and the timeout agree.
What RQ Scheduler does not tell you
RQ keeps started, finished and failed job registries in Redis and shows them in rq-dashboard or rq info. It has no notifications. A scheduled job that was never enqueued does not appear in any registry, and the rqscheduler process has no health endpoint; its absence is visible only in your process supervisor.
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.
Need a key? Get a free key · Stuck? contact