Docs › Kubernetes CronJob monitoring with RunVouch

Kubernetes CronJob monitoring with RunVouch

Kubernetes CronJob monitoring, the way kubectl cannot do it: a CronJob that reports Succeeded tells you the pod exited 0. It does not tell you the schedule was missed (startingDeadlineSeconds), the job produced nothing, or an agent inside it called the same tool 400 times.

How it runs on Kubernetes CronJob

The job runs in a pod from the CronJob's jobTemplate. Put rv in the image (pip install runvouch in the Dockerfile, or copy the single file) and wrap the container command.

Store the key

Store the key in a Secret and mount it as an environment variable: env: - name: RUNVOUCH_KEY valueFrom: secretKeyRef: {name: runvouch, key: api-key}.

Wrap the job

apiVersion: batch/v1
kind: CronJob
metadata: {name: nightly-report}
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: job
            image: ghcr.io/you/report:latest
            command: ["rv", "run", "nightly-report", "--evidence-file", "/out/report.html", "--", "python", "report.py"]
            env:
            - name: RUNVOUCH_KEY
              valueFrom: {secretKeyRef: {name: runvouch, key: api-key}}

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 Kubernetes CronJob

• The controller skips a run when it misses startingDeadlineSeconds; nothing pages you. RunVouch fires MISSED when cadence plus grace passes without a start.
• successfulJobsHistoryLimit keeps a few pods; a job that exits 0 with an empty output looks identical to a good one. --evidence-file makes the empty one FAILED with NO_EVIDENCE.
• With concurrencyPolicy: Allow a slow run overlaps the next; STALLED (max runtime) catches the slow one.

What Kubernetes CronJob does not tell you

The CronJob controller records lastScheduleTime and lastSuccessfulTime on the object and keeps a handful of finished pods, bounded by successfulJobsHistoryLimit and failedJobsHistoryLimit (defaults 3 and 1). There is no built-in notification: a schedule that stops firing, a job that exits 0 with nothing written, or a job killed by activeDeadlineSeconds only shows up if someone runs kubectl get cronjob and reads the timestamps. Alerting needs a separate stack (kube-state-metrics, Prometheus rules on kube_cronjob_next_schedule_time) that most clusters do not have wired for every job.

What RunVouch detects

Set up in two minutes

1. Get a free key (3 agents, no card) and store it where this page says.
2. wrap the job: copy the snippet above into the scheduled job.
3. 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.
4. 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?

systemd timers. GitLab CI scheduled pipelines. Jenkins. Heroku Scheduler. 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