$crond.io
← blog
2026-05-28 · 9 min read

How to Monitor Kubernetes CronJobs Without Modifying Your Images

Kubernetes CronJob resources are the cluster equivalent of a crontab — and they fail the same way: silently. A CronJob that hasn't scheduled a successful Pod in two weeks looks identical, in kubectl get cj, to one that ran ten minutes ago. The only difference is the LAST SCHEDULE column, which nobody is paid to read.

You can solve this with external heartbeat monitoring — a pinger checks in on every successful run, and you get paged when the pings stop. The tricky question is wherethe ping comes from when the workload lives in a container you don't control. This post covers the three patterns we see most often.

Pattern 1: bake the ping into the image

The simplest approach: append a curl call to the end of your container's entrypoint.

# Dockerfile
FROM python:3.12-slim
RUN apt-get update && apt-get install -y curl
COPY backup.py /app/
CMD python /app/backup.py && \
curl -fsS https://api.crond.io/ping/$PING_KEY

Works fine for greenfield images. Fails the moment you need to monitor a third-party container, a Helm chart you don't own, or a CronJob that shells out to multiple tools. The ping is also fragile: if the script returns 0 but didn't actually do its job, the ping still fires.

Pattern 2: an emptyDir sidecar with a wrapper script

When you can't (or don't want to) rebuild the image, you can mount a wrapper script via an init container, then exec the original entrypoint through it.

apiVersion: batch/v1
kind: CronJob
spec:
schedule: "0 2 * * *"
jobTemplate:
spec:
template:
spec:
initContainers:
- name: install-wrapper
image: ghcr.io/crond-io/crond-agent:latest
command: ["cp", "/usr/local/bin/crond-agent", "/shared/"]
volumeMounts: [{ name: shared, mountPath: /shared }]
containers:
- name: backup
image: original-image:v1.2
command: ["/shared/crond-agent", "wrap", "--name", "backup", "--", "/app/backup.sh"]

The wrapper captures exit code, duration, and stdout/stderr — so a backup script that fails partway through gets reported as a failure, not a success. Tradeoff: every CronJob manifest gets ~10 lines of boilerplate, and you have to remember to add the init container when you create new jobs.

Pattern 3: a mutating webhook (the Helm chart approach)

The boilerplate problem in pattern 2 goes away if a controller injects the wrapper automatically. A small mutating admission webhook can watch for CronJob resources with a specific annotation and inject the init container + command rewrite at admission time.

apiVersion: batch/v1
kind: CronJob
metadata:
annotations:
crond.io/monitor: "true"
crond.io/name: "backup"
spec:
# original spec, unchanged

Two annotations, no boilerplate per job, no image rebuild. This is the approach our crond-monitor Helm chart takes — install once, annotate your CronJobs, done.

A note on schedule drift

Kubernetes' CronJob controller does not guarantee on-time execution. If the API server is under load, or the controller is starved of resources, scheduled runs can be delayed by minutes. Set your grace period to account for this — we recommend at least 30s on top of expected runtime for sub-hour CronJobs, more for clusters under sustained pressure.

When each pattern fits

  • Bake into image: 1–3 CronJobs, all under your control, no plans to scale the number of monitored workloads.
  • EmptyDir sidecar:Third-party images you can't modify, but you still own the manifests. Good fit when you have < 10 CronJobs.
  • Mutating webhook / Helm chart: Dozens of CronJobs across many namespaces, or you want a self-service path for app teams to opt in without touching infrastructure.

Read the Kubernetes setup guide →

Related