Feature

Cron Job Monitoring - Because Silent Failures Are the Worst Failures

Your backup script ran every night for six months. Then it quietly stopped. Nobody noticed for two weeks. Fivenines expects a ping from every scheduled job - when one does not arrive on time, you hear about it instead of finding out from a restore that has nothing to restore.

Built for teams monitoring production infrastructure

Start free trial

No credit card · 2-minute setup

Heartbeats Late jobs Missed runs

14 jobs

1 late

last run 2m ago

Missed Run Detection

Chain the ping so it only fires when your script succeeds. A job that crashes, exits non-zero, or never starts simply never pings, and the missing ping is what pages you.
Late Job Detection

Every job carries its own grace period. Run past it and the job is marked late and an incident opens - so you know before downstream systems start serving stale data.
Cron in Your Timezone, or a Fixed Interval

Describe the schedule as a standard five-field cron expression, evaluated in the timezone you pick so a daylight-saving shift does not turn 2 AM local into a false alarm - or as a fixed interval counted from the last ping, for jobs that just run every N minutes.

What Teams Typically Monitor

Database backups

pg_dump, mysqldump, mongodump scripts

SSL certificate renewal

certbot or acme.sh renewal jobs

Data sync jobs

rsync, rclone, or API-based sync scripts

Log rotation & cleanup

logrotate and custom cleanup scripts

Report generation

Scheduled analytics, billing, or compliance reports

Health checks

Internal scripts that verify service dependencies

Multi-Channel Notifications

Get alerts via email, Slack, Microsoft Teams, Telegram, Discord, Pushover, PagerDuty or webhooks. Route different job alerts to different channels - backup failures to #ops-critical, report generation delays to #data-team.

How It Compares

How It Compares
Approach	Setup	Server Metrics
Check logs manually	None
Healthchecks.io	Per-job ping URL
Cronitor	Per-job ping URL
Fivenines	Ping URL	Built-in

How It Works

Create a task monitor, set the expected schedule (a five-field cron expression in the timezone you choose, or a fixed interval), then have your script POST to the ping URL it hands you - your-backup.sh && curl -X POST https://fivenines.io/ping/<key>. The && matters: chained that way the ping only fires when the job actually succeeded, so a crash, a non-zero exit or a run that never started all look the same to Fivenines - no ping. Once the expected time plus that job's grace period passes with no ping, the task is marked late and a workflow opens an incident and notifies your channels.

Frequently Asked Questions

How does Fivenines monitor cron jobs? +

You create a task monitor in the dashboard and get a unique ping URL. Have your script POST to that URL once it finishes successfully - chaining it with && is the usual recipe, so the ping only fires on success. Fivenines knows the schedule you configured and watches for pings arriving on time; a run that crashes, exits non-zero or never starts sends nothing, and that missing ping is what alerts you once the grace period passes.

Can I monitor cron jobs on multiple servers? +

Yes. Create task monitors for jobs on any server. Each gets its own ping URL. You see all monitored jobs across all servers in one place, and a job can optionally be linked to the instance it runs on for context.

What counts as a cron job monitor in the pricing? +

Each individual cron job you choose to track counts as one monitor. Plans bundle cron monitors with server, uptime, and network monitors under a single limit.

Does it work with systemd timers? +

Partly, and it is worth being precise about which part. A job run by a systemd timer is monitored exactly like a cron job: add the ping to the service's command and Fivenines watches for it on the schedule you configure here. Separately, Fivenines monitors systemd units directly on Linux hosts - the agent collects service, timer and socket units, and a workflow trigger alerts you when any unit (or a named list of them) enters the failed state, which covers a service launched by a timer blowing up. What is not built yet is reading the timer's own OnCalendar schedule into a task monitor, so late-run detection still comes from the schedule you enter, not from the timer definition.

Can I set different alert rules for different jobs? +

Yes. Each job carries its own schedule and its own grace period, so a nightly backup can be given hours of slack while a five-minute sync is flagged in minutes. A cron schedule is evaluated in the timezone you pick for that job; a fixed interval is simply counted from the last ping, so no timezone applies. Where the alert goes is a workflow decision, so different jobs can page different channels.

Explore next

Compare alternatives

See how Fivenines compares to other tools

vs HetrixTools

Read our guide to the best infrastructure monitoring tools in 2026.

Stop guessing whether your cron jobs ran

14-day trial. No credit card required.

Start free trial

No credit card · 2-minute setup · Cancel anytime

Learn more: What is a cron job in Linux · Cron Expression Generator

Cron Job Monitoring - Because Silent Failures Are the Worst Failures

Missed Run Detection

Late Job Detection

Cron in Your Timezone, or a Fixed Interval