Monitoring Cron Jobs in Docker and Kubernetes

Containerised scheduling adds new silent-failure modes: a CronJob suspended during a deploy, an image that fails to pull, a node with no capacity, or concurrencyPolicy quietly skipping runs. Cluster health looks fine while the job never executes.

Kubernetes CronJob

Add the ping to the container command so it only fires on success:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-backup
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: backup
              image: myorg/backup:latest
              command: ["/bin/sh", "-c"]
              args:
                - backup.sh && curl -fsS https://api.cronguard.dev/v1/ping/<your-uuid>

Why kubectl status isn’t enough

• A suspended CronJob shows no failures — it simply produces nothing.
• successfulJobsHistoryLimit prunes history, so past failures disappear.
• ImagePullBackOff or scheduling failures mean the Job never runs the command at all.
• Nobody is watching kubectl at 3am — you need a push alert.

Docker / docker-compose

# host crontab running a one-off container
0 3 * * * docker run --rm myorg/backup:latest && curl -fsS https://api.cronguard.dev/v1/ping/<your-uuid>

Monitor it with CronGuard

Create a monitor per CronJob, set the schedule and grace period, and CronGuard alerts you the moment a containerised job misses its run — across multiple channels, with no sidecar or agent to deploy. Free to start.