Docs › Dagster schedule monitoring with RunVouch
Dagster schedule monitoring with RunVouch
Dagster schedule monitoring for the daemon nobody watches: schedules and sensors in Dagster are executed by the dagster-daemon. When it is down, unhealthy or pointed at a stale code location, nothing runs and the UI shows a status you have to go and look at.
How it runs on Dagster
Inside an op or asset with the Python client, or wrap the run launcher command for a whole job. One agent per job or per critical asset.
Store the key
An environment variable on the code location (Dagster+ env vars, or the container env for OSS); read it with EnvVar("RUNVOUCH_KEY") in a resource.
Wrap the job
from dagster import asset, ScheduleDefinition, define_asset_job, Definitions
import os, runvouch
@asset
def nightly_report():
with runvouch.vouch("nightly-report", evidence=lambda: {"report": os.path.exists("out/report.html")}) as run:
rows = extract()
run.tool("llm.summarise", {"rows": len(rows)}, cost=0.03)
write_report(rows)
job = define_asset_job("nightly_report_job", selection=[nightly_report])
defs = Definitions(assets=[nightly_report], jobs=[job],
schedules=[ScheduleDefinition(job=job, cron_schedule="0 2 * * *")])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 Dagster
- A stopped daemon or a schedule left in the Stopped state after a redeploy produces no runs; MISSED after cadence plus grace.
- An asset materialised with zero rows is a successful materialisation; evidence is the check.
- Run retries (
max_retries) re-execute LLM ops; the per-run cost cap holds across the retry.
What Dagster does not tell you
The Dagster UI shows daemon health on the Deployment page and marks a schedule as running or stopped; run failure hooks and alert policies (Dagster+) fire on runs that exist. A daemon that is not running, a schedule that came back Stopped after a redeploy, or a code location that failed to load, all result in no run and therefore no failure to alert on.
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?
Celery beat. APScheduler (in-process). Temporal Schedules. Windmill. 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