Cron Job Monitoring That Alerts You the Moment a Scheduled Job Fails to Run
A cron job that silently stops is worse than one that loudly fails. Uptimehub gives your background jobs a dead-man switch so a missed run never goes unnoticed.
Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
In short
Cron job monitoring, also called heartbeat monitoring, confirms that a scheduled or background task actually ran by expecting a regular signal from it. With Uptimehub you give each job a unique ping URL and have it call that URL when it finishes successfully, so the job itself reports in. If the expected ping does not arrive within the window you define, Uptimehub treats the job as failed and alerts you in seconds through Slack, email, SMS, or webhook. This dead-man-switch approach catches the silent failures that traditional uptime checks miss entirely, like a backup that never started or a queue worker that quietly died. There is nothing to install, since the job simply makes one outbound HTTP request when it completes.
What you get
Cron monitoring for developers, SaaS teams and agencies
Dead-man switch
If the expected heartbeat is missing or late, Uptimehub alerts you, so a job that silently stops can no longer go undetected.
One line to integrate
Have your job hit a unique ping URL when it finishes. No agent, no SDK, just one outbound HTTP request.
Custom schedules and grace
Define how often each job should run and how much lateness to tolerate, matching real cron and queue timing.
Covers backups and workers
Perfect for backups, ETL jobs, queue workers, and nightly reports where a missed run is the real risk.
How it works
From URL to alert in four steps
Create a heartbeat monitor
Set the expected interval and grace period, then copy the unique ping URL Uptimehub gives you.
Your job pings on completion
Add a call to that URL at the end of your cron job or scheduled task.
We watch for the ping
Uptimehub expects the heartbeat on schedule and starts a countdown if it is missing.
Get alerted if it is late
When a ping is late or absent, you get an instant alert so you can rerun the job.
On this page
Getting the schedule right is the other half of the job
Heartbeat monitoring tells you a job did not run. It cannot tell you that the job was never going to run at the time you intended, because the expression you wrote does not mean what you read it as. That failure is quieter still: the job runs perfectly, on the wrong schedule, and everything downstream is a day or an hour out.
The reason this happens so often is that cron syntax is not one standard. A schedule written on a Linux box gets pasted into a Kubernetes manifest, a Spring annotation, a Quartz trigger, an EventBridge rule or an Azure timer, and those dialects disagree on field count, on whether seconds exist, and above all on how the days of the week are numbered.
| Scheduler | Fields | Seconds | Day of week | Sunday is | Default time zone |
|---|---|---|---|---|---|
| Unix / Linux crontab | 5 | No | 0 to 7 | 0 and 7 both | System local time |
| Kubernetes CronJob | 5 | No | 0 to 6 | 0 | Controller time, or .spec.timeZone |
| Spring @Scheduled | 6 | Yes | 0 to 7 | 0 and 7 both | Server default, or the zone attribute |
| Quartz (Java and .NET) | 6 or 7 | Yes | 1 to 7 | 1 | Trigger time zone |
| AWS EventBridge | 6 | No | 1 to 7 | 1 | UTC, always |
| Azure Functions NCRONTAB | 6 (5 accepted) | Yes | 0 to 6 | 0 | UTC, or WEBSITE_TIME_ZONE |
Read the Sunday column again, because it is the expensive one. A day of week digit of 5 means Friday in a Linux crontab and Thursday in Quartz or EventBridge. Both are valid values in both families, so nothing errors and no log line records it. The job simply moves a day and keeps running. Writing SUN to SAT names rather than numbers removes the entire problem at no cost.
The second trap is that when both the day of month and the day of week fields are restricted, Unix cron runs the job when either one matches rather than both. So a schedule of 0 0 1 * MON is not the first of the month when it falls on a Monday: it is the first of the month, and also every Monday, which is around five times the intended number of runs.
Our cron expression generator and explainer reads any expression back in plain English, shows the next five run times in your own time zone and in UTC, and warns when the weekday numbering will not survive a move between schedulers. If a job is already missing its schedule, why a cron job does not run at its scheduled time works through the causes in the order that finds them fastest.
FAQ
Questions buyers ask about Cron monitoring
Cron job monitoring watches whether your scheduled tasks actually ran and finished, rather than assuming they did. The job pings a unique URL when it completes, and if that ping does not arrive inside the window you set, the monitor alerts you. It is the only reliable way to catch a job that stopped running entirely.
A failed cron job usually leaves no trace, because cron mails output to a local mailbox nobody reads and a job that never started produces no output at all. Heartbeat monitoring inverts the problem: instead of watching for a failure signal, you watch for the success signal and alert on its absence.
A heartbeat monitor is a check that expects your system to contact it on a schedule instead of the other way round. You add one line to the end of your job to hit a unique URL. If the expected ping is late by more than the grace period, the monitor treats that silence as a failure and alerts.
Set the expected interval to 24 hours and add a grace period that covers normal variation in runtime, typically 15 to 60 minutes for a nightly job. The monitor then alerts only when the ping is later than the schedule plus the grace window, so a job that runs 10 minutes late does not wake anyone.
The usual causes are a server rebuild that dropped the crontab, a changed path or environment variable after a deploy, a user account that was removed, a disk that filled up, or a job that now overruns its own schedule and blocks the next run. None of these announce themselves, which is why backups often turn out to have been broken for months.
Last updated July 2026
More monitor types
Start monitoring in two minutes
Add a URL or endpoint and Uptimehub checks it every minute from 6 global regions, alerts you in seconds, and updates your branded status page. Read-only checks that never touch your servers.