How to Monitor Cron Jobs in 2026: Stop Flying Blind

Your cron job failed three days ago. You just found out. Sound familiar?

Silent cron failures are one of the most common — and most preventable — causes of production incidents. A backup job stops running, a data sync breaks, an invoice generator dies quietly. By the time anyone notices, the damage is done.

This guide covers everything you need to know about monitoring cron jobs: why they fail, how to detect failures, and the best tools to set up dead-simple monitoring in under 5 minutes.

Why Cron Jobs Fail Silently

Cron itself has no built-in concept of "this should have run but didn't." Common failure modes include:

• The job crashes — an unhandled exception kills the process, cron doesn't care
• The job hangs — stuck on a network call or lock, never completes
• The server reboots — crontab survives but the environment doesn't (missing env vars, unmounted disks)
• Disk full — job can't write output, fails silently
• Permission changes — OS update changes file permissions, job can't execute
• Time drift — NTP issues cause jobs to run at wrong times or overlap

The pattern is always the same: nothing alerts you. You find out when a customer complains or when you manually check.

The Dead Man's Switch Pattern

The most reliable way to monitor cron jobs is the dead man's switch (also called heartbeat monitoring or check-in monitoring):

1. Your cron job pings a URL when it succeeds
2. The monitoring service expects that ping on a schedule
3. If the ping doesn't arrive on time, you get alerted

This catches every failure mode: crashes, hangs, server issues, even "someone deleted the crontab" scenarios. If the job doesn't run, the ping doesn't happen, and you know immediately.

Basic Implementation

Add a single curl call to the end of your cron job:

# Before: just the job
0 * * * * /usr/local/bin/backup.sh

# After: ping on success
0 * * * * /usr/local/bin/backup.sh && curl -fsS https://cronping.grabshot.dev/api/ping/YOUR_CHECK_ID

Monitoring Long-Running Jobs

For jobs that take minutes or hours, ping at the start AND end:

# Ping start, run job, ping end (or fail)
0 2 * * * curl -fsS https://cronping.grabshot.dev/api/ping/abc123/start && \
  /usr/local/bin/big-export.sh && \
  curl -fsS https://cronping.grabshot.dev/api/ping/abc123

This lets you detect jobs that started but never finished — the classic "hanging job" problem.

Cron Monitoring Tools Compared

Tool	Free Tier	Starting Price	Best For
CronPing	5 monitors	$9/mo	Developers who want a simple API
Healthchecks.io	20 monitors	$20/mo	Open-source self-hosters
Cronitor	5 monitors	$24/mo	Teams with many jobs
Better Uptime	10 monitors	$29/mo	Combined uptime + cron monitoring
Dead Man's Snitch	1 monitor	$5/mo	Minimal, one critical job

Setting Up Monitoring in Node.js

If your scheduled jobs run in Node.js (using node-cron, Agenda, Bull, or similar), wrap them with a ping:

const cron = require('node-cron');

cron.schedule('0 * * * *', async () => {
  try {
    await runMyJob();
    // Ping on success
    await fetch('https://cronping.grabshot.dev/api/ping/YOUR_CHECK_ID');
  } catch (err) {
    console.error('Job failed:', err);
    // No ping = alert fires automatically
  }
});

Setting Up Monitoring in Python

import requests
import subprocess

def run_and_ping(command, check_url):
    result = subprocess.run(command, shell=True)
    if result.returncode == 0:
        requests.get(check_url, timeout=10)
    else:
        raise Exception(f"Job failed with code {result.returncode}")

# Usage
run_and_ping(
    "python /app/daily_report.py",
    "https://cronping.grabshot.dev/api/ping/YOUR_CHECK_ID"
)

What to Monitor Beyond Cron

Once you have cron monitoring set up, extend the pattern to other scheduled processes:

• Database backups — verify the backup actually completed and the file isn't empty
• Queue workers — heartbeat every N minutes to prove the worker is alive
• Batch processing — ping after each batch completes
• Certificate renewal — monitor Let's Encrypt renewal crons
• Log rotation — make sure logrotate is actually running
• Health checks — periodic self-tests that verify your app can reach its dependencies

Best Practices

1. Set grace periods — allow some slack for job duration variance (if a job usually takes 5 minutes, set a 15-minute grace period)
2. Monitor exit codes — only ping on success (exit code 0)
3. Include job output — some tools let you POST the job output for debugging
4. Use multiple alert channels — email + Slack/Discord so you actually see it
5. Test your monitoring — intentionally break a job and verify you get alerted
6. Document your crons — maintain a list of all scheduled jobs and their monitoring URLs

Conclusion

Cron job monitoring is one of those things that takes 5 minutes to set up and saves you hours of debugging. The dead man's switch pattern is simple, reliable, and catches every type of failure.

Pick a tool, add a curl call to your cron jobs, and stop worrying about silent failures. Your future self will thank you.