Docs › APScheduler monitoring with RunVouch
APScheduler monitoring with RunVouch
APScheduler monitoring from outside the process it lives in: APScheduler runs inside your application process. When that process is restarted at the wrong moment, crashes or is scaled to zero, the schedule goes with it and nothing outside knows.
How it runs on APScheduler (in-process)
Inside the scheduled function with the Python or Node client. The agent's cadence is what makes the missing process visible.
Store the key
An environment variable on the process.
Wrap the job
from apscheduler.schedulers.blocking import BlockingScheduler
import runvouch
def nightly_report():
with runvouch.vouch("nightly-report", evidence=lambda: {"rows": n > 0}) as run:
n = build_report(run)
sched = BlockingScheduler()
sched.add_job(nightly_report, "cron", hour=2, minute=0, misfire_grace_time=3600)
sched.start()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 APScheduler (in-process)
- A job missed while the process was down is dropped after
misfire_grace_time; with the default (1 second in APScheduler 3) it is dropped almost always. - Two replicas of the process run the job twice; RunVouch shows both runs under one agent, and the daily cost cap counts both.
- A process stuck on a lock still looks alive to the orchestrator; STALLED catches the run that never ends.
What APScheduler (in-process) does not tell you
APScheduler emits events (EVENT_JOB_ERROR, EVENT_JOB_MISSED) that your code can listen to, inside the same process that may be the thing that died. A job that was due while the process was down is dropped when misfire_grace_time passes, and in APScheduler 3 that default is one second. Nothing is persisted unless you configure a job store, and nothing is sent anywhere unless you write the listener.
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 orchestrators?
Temporal Schedules. Windmill. node-cron. PM2 cron restart. 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