Docs › Celery beat monitoring with RunVouch
Celery beat monitoring with RunVouch
Celery beat monitoring for a process with no watchdog: Celery beat is a single process that publishes tasks on a schedule. If it dies, or a worker for that queue is not running, tasks are late or never run, and Flower will not page you.
How it runs on Celery beat
Inside the task function with the Python client (recommended), or wrap the worker-side command if the task shells out.
Store the key
An environment variable on the worker processes; beat itself does not need the key.
Wrap the job
from celery import Celery
from celery.schedules import crontab
import runvouch
app = Celery("jobs", broker="redis://redis:6379/0")
app.conf.beat_schedule = {"nightly-report": {"task": "jobs.nightly_report", "schedule": crontab(hour=2, minute=0)}}
@app.task(bind=True, max_retries=2)
def nightly_report(self):
with runvouch.vouch("nightly-report", evidence=lambda: {"rows": n > 0}) as run:
n = build_report(run)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 Celery beat
- Beat down means no task is even published; MISSED is the only external signal.
- A task that is published but never consumed (wrong queue, no worker) is neither failed nor succeeded; it is a MISSED start.
max_retriesaround an LLM call repeats the spend; the per-run cost cap and retry-storm detector cover it.
What Celery beat does not tell you
Celery has no notification of its own. Flower shows workers and tasks it has seen; a task that beat never published because beat is down does not appear anywhere, and a task published to a queue no worker consumes sits in the broker as a message. Task-level failure handling (on_failure, task_failure signal) requires the task to have started.
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?
APScheduler (in-process). Temporal Schedules. Windmill. node-cron. 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