Docs › GitLab CI scheduled pipeline monitoring with RunVouch
GitLab CI scheduled pipeline monitoring with RunVouch
GitLab CI scheduled pipeline monitoring for the failure GitLab does not report: pipeline schedules run as the user who created them. When that user leaves or the schedule is deactivated the pipeline silently stops, and a job that passes is not a job that did the work.
How it runs on GitLab CI scheduled pipelines
Inside the job's script:. The runner image needs Python 3 (pip install runvouch) or the single rv file fetched with curl.
Store the key
Add RUNVOUCH_KEY as a masked, protected CI/CD variable (Settings, CI/CD, Variables).
Wrap the job
nightly-report:
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
script:
- pip install -q runvouch
- rv run nightly-report --evidence-file public/report.html -- python report.py
artifacts:
paths: [public/report.html]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 GitLab CI scheduled pipelines
- A deactivated schedule, or one whose owner lost access to the project, stops without a notification. MISSED covers it.
- Pipeline notifications fire on failure, not on "passed but wrote nothing";
--evidence-filedoes. - Retried jobs (
retry:) can run an LLM step several times; the retry-storm and per-run cost cap see the repeats.
What GitLab CI scheduled pipelines does not tell you
GitLab e-mails and integrations fire on pipeline status: failed, fixed, or success if you opt in. They never fire for a pipeline that did not run. A schedule owned by a user who was removed from the project, or a schedule that was deactivated by hand, stays in the list with its next-run time and simply never creates a pipeline. A job that passes with an empty artifact is a passed job.
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 schedulers?
Jenkins. Heroku Scheduler. Claude Code scheduled tasks. OpenClaw automations and heartbeat. 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