Kubernetes CronJobs are great until they quietly fail. Maybe the pod image can't pull, or the job exceeds backoff limits. CronObserver adds a simple heartbeat so you know when jobs don't run on time.
Why use heartbeats on CronJobs?
- CronJobs can be suspended/deleted during deploys.
- Out-of-resource errors happen silently.
- Logs rotate quickly; by the time you investigate, the evidence is gone.
A single HTTP check-in after the pod completes is enough to warn you.
Step 1 – Create an observer
Define schedule/grace to match the CronJob.
Schedule: */30 * * * *
Grace: 5 minutes
Alerts: Email + webhook (Slack/Teams)
Step 2 – Store the URL in a secret
apiVersion: v1
kind: Secret
metadata:
name: cronobserver-checkin
stringData:
url: https://cronobserver.com/checkin/<token>
Mount the secret as an env var:
env:
- name: CRONOBSERVER_CHECKIN_URL
valueFrom:
secretKeyRef:
name: cronobserver-checkin
key: url
Step 3 – Curl after the job completes
command: ["sh", "-c", "run-task && curl -fsS -X POST $CRONOBSERVER_CHECKIN_URL"]
Alternative: wrap your script to post success/failure status in JSON.
command: [
"sh",
"-c",
"run-task && curl -fsS -X POST $CRONOBSERVER_CHECKIN_URL -H 'Content-Type: application/json' -d '{\"status\":\"success\"}'"
]
Optional – Synthetic checks
Instead of waiting for a job to ping, CronObserver can proactively ping your endpoint.
synthetic_check:
type: httpGet
url: https://api.example.com/cron/health
expected_status: 200
timeout_seconds: 10
Great for queue processors or serverless schedulers.
Alerting
- Email or webhook per observer.
- Webhook works with Slack, Teams, Zapier.
- Grace periods and cooldowns reduce noise.
Links
👉 Monitor your first CronJob free: cronobserver.com/sign-up
Top comments (0)