How to Monitor Cron Jobs and Know When They Stop Running

Your cron job ran every night for six months. Then it stopped. You found out three weeks later when a customer asked why their data export was empty.

This is the most common failure mode in operations: silent schedule failures. No error log, no crash alert, no signal at all — just a task that quietly stops running.

Why cron jobs fail silently

Uptime monitoring can't catch this. Your server is up, your app is running, HTTP returns 200. Everything looks fine — except the nightly database cleanup hasn't run in two weeks.

Cron jobs fail for dozens of reasons that don't trigger alarms:

• The server rebooted and crontab didn't survive
• A package update changed a dependency path
• Disk filled up and the script exited early
• Someone edited the crontab and introduced a syntax error
• The script runs but errors silently (exit code 0 with no actual work done)

None of these produce a signal you can monitor reactively. You need a system that notices the absence of activity.

How heartbeat monitoring works

Heartbeat monitoring flips the model. Instead of a service checking your infrastructure, your infrastructure checks in with the service. If it stops checking in, you get an alert.

The setup is simple:

1. Create a heartbeat monitor with an expected interval (e.g., every hour)
2. Get a unique URL endpoint
3. Add a single line to the end of your cron job that pings that URL
4. If the ping doesn't arrive on schedule, the monitor goes down and you get alerted

Here's what that looks like in practice:

Bash (at the end of your cron script):

#!/bin/bash
# Your actual job
/usr/local/bin/run-backup.sh

# Ping heartbeat on success
curl -fsS https://poppaping.com/heartbeat/YOUR_TOKEN

Python:

import requests

def main():
    # Your scheduled task logic
    process_reports()

    # Signal completion
    requests.get("https://poppaping.com/heartbeat/YOUR_TOKEN")

The key insight: only ping the heartbeat after your job succeeds. If the script crashes halfway through, the ping never fires, and you get alerted.

What to monitor with heartbeats

Any task that runs on a schedule and would cause problems if it stopped:

• Database backups — the one you'll wish you had monitored when the restore fails
• Log rotation — disks fill up fast when cleanup stops
• SSL certificate renewal — Let's Encrypt auto-renew is great until it isn't
• Data syncs and ETL pipelines — stale data compounds silently
• Report generation — your CEO's Monday morning dashboard shouldn't be blank
• Queue workers — if the consumer dies, the queue backs up without a sound
• Cleanup scripts — temp files, expired sessions, orphaned records

Setting up a grace period

Jobs don't always finish at the exact same time. A backup that normally takes 10 minutes might take 25 minutes on a busy day. You don't want a false alarm because the job was slow.

Grace periods solve this. Set your expected interval to match the cron schedule (e.g., 1 hour), and add a grace period for variance (e.g., 10 minutes). The monitor only alerts if the heartbeat is missing for interval + grace — giving your job room to breathe.

A real example

Say you have a nightly backup at 2:00 AM that typically takes 5-15 minutes:

• Heartbeat interval: 24 hours (once per day)
• Grace period: 30 minutes
• Cron entry: 0 2 * * * /opt/scripts/backup.sh && curl -fsS https://poppaping.com/heartbeat/abc123

If the backup finishes at 2:12 AM, the heartbeat fires. All good. If the backup fails, hangs, or the cron job itself doesn't run, no heartbeat arrives. At 2:30 AM (interval + grace), you get an alert.

You went from "finding out three weeks later" to "finding out 30 minutes later."

Getting started

PoppaPing's heartbeat monitoring is available on all paid plans starting at $5/month. Create a heartbeat monitor, grab your unique URL, and add it to your scripts. Takes about 60 seconds per job.

The cron job that stops running doesn't announce itself. Heartbeat monitoring makes sure you hear about it anyway.