Cron Job Monitoring: Know the Night Your Backup Doesn't Run

Cron is famously reliable at one thing: failing silently. A deleted crontab line, a migrated server, a full disk, an expired credential — the job just stops, and nothing tells you. Add one curl line to the job and we watch its schedule: no ping after the expected run means an alert in your hands, the same night — not three weeks later.

Purpose-Built for Scheduled Jobs

Not a generic pinger — a monitor that understands cron schedules, exit codes and run durations

Real Cron Expressions

Define the expectation with the same 5-field cron line your crontab uses — 0 3 * * * means we expect a ping shortly after 03:00 every night, not merely “sometime today”.

Timezone-Aware Schedules

Every cron monitor evaluates in the timezone you pick — DST shifts included — so a 03:00 job in Vilnius is checked at 03:00 Vilnius time, not 03:00 UTC.

Grace That Matches Reality

Backups don't finish at the same second every night. The grace period forgives normal runtime variance — alert only when the job is genuinely overdue.

Exit-Code Reporting

Append /$? to the ping and the job's real exit code travels with it. Non-zero codes raise a “run failed” alert — distinct from “never ran” — with the code in the incident.

Run Duration Trends

Start/finish ping pairs measure every run. Watch the nightly dump grow from 4 to 40 minutes across a quarter, and set an alert threshold before it collides with business hours.

Output Attached to Every Run

Capture the job's stdout/stderr and POST it with the ping (up to 10 KB). When a run fails, pg_dump's actual error is already in the incident — no SSH archaeology.

First-Miss Incidents

A daily job that misses once has already missed a day — so a single missed window opens an incident immediately, and the next successful run resolves it automatically.

Drop-In Migration

Ping URL conventions are Healthchecks-compatible: if your scripts already curl a check-in endpoint, migrating is a domain swap — the /start, /fail and exit-code paths keep working.

Why Monitor Cron Jobs at All?

Because the jobs cron runs are usually the ones with the highest cost of silent failure: backups, billing exports, certificate renewals, report generation, data retention cleanups. When one stops, nothing breaks visibly — until the day you need the backup that doesn't exist. Cron monitoring converts that class of disaster into a same-day notification, for the cost of one line per crontab entry. And it's a regular monitor on every plan, Free included — no separate cron-monitoring bill.

Start monitoring now

Know the same night a scheduled job doesn't run — not weeks later

One crontab line: && curl -fsS <your-ping-url> after the job

Cron-expression expectations with full timezone and DST handling

“Didn't run”, “ran but failed” and “ran too long” are three distinct alerts

Job output stored with each run for instant root-cause reading

Works with crontab, systemd timers, Kubernetes CronJobs, Windows Task Scheduler

Incidents auto-resolve on the next successful run

Counts as a normal monitor — included in the Free plan

How Cron Job Monitoring Works

Your crontab does one extra curl — we do the worrying

1

Mirror the Schedule

Create a cron monitor with the same expression as your crontab entry (e.g. 0 3 * * *), its timezone, and a grace period that covers the job's normal runtime.

2

Chain the Ping

Append the ping to the job: /usr/local/bin/backup.sh && curl -fsS <your-url> — with &&, the ping only fires when the job actually succeeded.

3

Every Slot Is Checked

After each scheduled occurrence, we wait for the ping until the slot plus grace expires. On time — green. Reported failure — “run failed”. Silence — “missed schedule”.

4

Alert, Diagnose, Auto-Resolve

Incidents open on the first miss with job-side diagnostic hints and the run's attached output. The next successful check-in closes the incident automatically.

Cron Jobs Worth Watching

Anything scheduled is something that can silently stop

Database Backups

The canonical case: pg_dump or mysqldump at 03:00, discovered broken only during a restore attempt. With exit-code pings and attached output, you know at 03:05 — with the error message included.

Billing, Reports & Exports

Invoice generation, end-of-day settlement, warehouse exports — jobs whose absence costs money or compliance. A cron monitor per job turns “finance noticed on Friday” into “ops knew in a minute”.

Certificate & Credential Renewals

certbot renew, key rotation, token refresh scripts. When a renewal job dies, everything works — until the expiry date. The heartbeat catches the dead job months before the outage it would cause.

Cleanups & Retention Jobs

Log rotation, temp-file purges, GDPR retention deletes. Silent failure here means full disks and compliance drift. A weekly job with a day of grace keeps them honest without noise.

Frequently Asked Questions

Everything you need to know about cron job monitoring

Cron job monitoring verifies that scheduled jobs actually run when they should. Your job pings a unique URL when it completes; we know the schedule (a real cron expression with its timezone) and alert you when a ping doesn't arrive within the expected slot plus grace — or when the job reports a failure or runs too long. It catches the failure mode cron itself never reports: not running at all.

From our blog

Guides, deep-dives, and best practices from the WatchFor team

Stop Trusting Cron Blindly

Every crontab has a job that quietly matters. Give each one a single curl line and sleep better — the next time a backup doesn't run, you'll be the first to know, not the last. Start free, no credit card required.