Monitor Kubernetes CronJobs
A Kubernetes CronJob's failure modes — a forgotten suspend: true, a run skipped by concurrencyPolicy, a pod that never schedules — often don't surface anywhere unless you go looking with kubectl. A ping at the end of the container's command closes that gap.
Setup
Create an incoming monitor
Add a heartbeat monitor in Pingtastic matching the CronJob's schedule.
Append a ping to the container's command
After the real work succeeds, curl the ping URL as part of the same shell command.
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-report
spec:
schedule: "0 6 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: report
image: myorg/report-generator:latest
command:
- sh
- -c
- "./generate-report.sh && curl -fsS https://ping.pingtastic.net/ping/nightly-report"
restartPolicy: OnFailureGotchas
- ⚠A CronJob set to suspend: true (often toggled during an incident and forgotten) stops creating Jobs entirely with no error anywhere in kubectl's normal output — a missed ping is often the first real signal.
- ⚠concurrencyPolicy: Forbid silently skips a scheduled run if the previous Job is still active — worth knowing before assuming a missed ping means the job itself failed.
Questions
Does kubectl get cronjob show failures?
It shows the CronJob's own recent-run history, but nothing proactively alerts you — you have to go looking. A heartbeat ping flips that into something that alerts you instead.
What if the pod fails to schedule (e.g. resource limits)?
The container's command never runs, so the ping never fires — correctly surfacing as a missed check-in even though the failure is at the cluster-scheduling level, before your code even starts.
Start monitoring your Kubernetes cronjobs
Set up your first monitor in under five minutes.
Get started — $5/month