Cron job monitoring: catch the run that never happened

Scheduled jobs are the quiet workers of every system: backups at night, invoices on the first of the month, data syncs every ten minutes. They have one dangerous property – when they stop, nothing visibly breaks. No error page, no angry customer, just a job that silently did not run. Cron job monitoring, also called heartbeat monitoring, turns that silence into an alert. This guide explains how heartbeat checks work, how to set them up for crontab, Windows Task Scheduler, application code and devices behind a firewall, how to choose interval and grace period, and which mistakes leave gaps.

What is cron job monitoring?

Cron job monitoring checks whether scheduled tasks and background jobs actually run, and run on time. Most monitoring works by polling: a monitor sends a request to your website or server and evaluates the response. A cron job has nothing to poll – it has no public page and no port, and between runs it does not exist at all. So the direction is reversed. Each monitored job gets a unique URL, and the job calls that URL when it has done its work. This call is the heartbeat.

The monitor knows the expected rhythm: every ten minutes, every night, once a month. As long as heartbeats arrive on schedule, the monitor is up. If one is missing after the expected interval plus a grace period, the monitor goes down and sends an alert. That is why the technique is also called heartbeat monitoring, dead man’s switch or check-in monitoring – it reacts to something that did not happen, which is exactly the failure mode of scheduled jobs.

What is a cron job?

A cron job is a task that a scheduler starts automatically at fixed times or intervals. The name comes from cron, the time-based scheduler of Unix and Linux systems. Each line in a crontab file contains five time fields – minute, hour, day of month, month and day of week – followed by the command to run. Windows has the same concept under the name Task Scheduler, and cloud platforms offer scheduled functions, Kubernetes CronJobs and CI pipelines with timed triggers.

# ┌ minute  ┌ hour  ┌ day of month  ┌ month  ┌ day of week
  0         2       *               *        *       /usr/local/bin/backup.sh
  */10      *       *               *        *       /usr/local/bin/sync.sh
  0         6       1               *        *       /usr/local/bin/invoices.sh

Teams use cron jobs for database backups, log rotation and cleanup, certificate renewals, report generation, newsletter sending, cache rebuilds, imports from partner systems and syncing data between applications. Writing the schedule correctly is the first step; a cron expression generator turns phrases like “every weekday at 07:30” into the right five fields and shows the next run times, so you can check the schedule before relying on it.

Why scheduled jobs fail silently

A web server that fails produces visible symptoms. A cron job that fails usually produces none. The reasons are many: the server was rebuilt and the crontab was not migrated, a deployment changed a path, the job’s credentials expired, the disk filled up, a dependency started hanging so the job never finishes, the cron daemon itself stopped, or a container platform rescheduled the workload and the timer was lost. In each case, the job simply does not report back.

Classic cron sends output by local mail, which in practice lands in a mailbox nobody reads. Log files record errors but only if the job starts at all, and nobody reads them until something is already missing. The cost shows up later and is often large: the backup you need after an incident turns out to be three weeks old, customers did not receive invoices, a sync gap corrupted reports. A heartbeat monitor makes the absence visible within one interval.

Which tasks should you monitor?

A useful rule: if a task failing for a day would create a real problem, monitor it. In practice that covers most jobs that touch data, money or customers, and many that keep systems healthy.

• Database and file backups, including off-site copies
• SSL certificate renewals (for example certbot or acme.sh runs)
• Billing runs, invoice generation and payment exports
• Data syncs and imports between systems, CRM and shop
• Email and newsletter sending jobs, queue workers
• Report generation and scheduled exports for customers
• Cache rebuilds, search index updates, sitemap generation
• Cleanup scripts for logs, temp files and old sessions

Heartbeat monitoring compared with other monitor types

Website, ping, port and keyword monitors are active checks: they confirm that a service is reachable. A heartbeat monitor is passive: it confirms that a task actually ran. The two answer different questions, and a healthy server can run broken jobs for weeks. That is why cron job monitoring is used for background workers, scheduled scripts and data pipelines – processes without a public endpoint to check.

How heartbeat checks work: interval and grace period

Two settings define a heartbeat monitor. The interval is how often a ping is expected – it should match the job’s schedule, so ten minutes for a job that runs every ten minutes and 24 hours for a nightly backup. Services typically allow anything from one minute up to about a month, which covers frequent workers as well as monthly billing exports.

The grace period absorbs normal variation. A backup that usually takes five minutes may take forty on the night after a big import; a job queued behind others may start a little late. The grace period is the extra time the monitor waits after the expected ping before alerting. Set it slightly longer than the slowest normal run, not much longer: a grace period of a day on a nightly job means you learn about a failure a day and a half late. Review it when job durations change.

How to set up cron job monitoring

Setting up a heartbeat monitor usually takes four steps. Create a monitor of the cron job or heartbeat type and give it a descriptive name, such as “Nightly DB backup – db01”. Set the interval to the job’s schedule and add a grace period. Copy the unique ping URL the service generates for this monitor. Finally, add a request to that URL at the end of your job, so that it is only sent when the work has been done.

Then test the setup in both directions: run the job manually and check that the heartbeat shows up, and temporarily disable the ping to confirm that an alert actually arrives. Many failures of monitoring are failures of untested monitoring.

• One monitor per job – never share a ping URL between jobs
• Interval = schedule, grace period = slowest normal run plus a margin
• Ping at the end, and only after a successful exit
• Test once by skipping the ping and waiting for the alert

Sending heartbeats from crontab with curl or wget

On Linux, the simplest heartbeat is a curl or wget call appended to the cron line. Most services accept both GET and POST requests. The important detail is the operator: “&&” runs curl only if the job exited with status 0, so a crashed backup sends no heartbeat and triggers the alert. A semicolon would ping after every run, including failed ones, and the monitor would happily report success.

0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://monitor.example/ping/8f3a…
# only pings if backup.sh exited with status 0
*/10 * * * * /usr/local/bin/sync.sh; wget -q -O /dev/null https://monitor.example/ping/c41d…
# pings after every run, even a failed one – usually not what you want

Add a timeout and a few retries to the ping (curl -m 10 --retry 3) so that a short network hiccup does not cause a false alarm, and silence curl’s output with -fsS so cron does not send mail for every successful ping. For longer scripts, put the ping as the last line inside the script itself, after any checks that the result is valid – for example that the backup file exists and is not empty.

Windows Task Scheduler and PowerShell

The same pattern works on Windows. A scheduled task in Task Scheduler runs a PowerShell script; at the end of the script, Invoke-RestMethod or Invoke-WebRequest sends the heartbeat. Check $LASTEXITCODE or wrap the work in try/catch so that the request is only sent after success. If the task fails to start – because the account password changed, the machine was asleep or the trigger was disabled – no heartbeat arrives and the monitor alerts.

& C:\Jobs\export.ps1
if ($LASTEXITCODE -eq 0) {
  Invoke-RestMethod -Uri "https://monitor.example/ping/5be2…" -Method Post -TimeoutSec 10
}

Give the request a short timeout and make sure the server running the task can make outbound HTTPS requests; corporate proxies are a frequent reason for heartbeats that never leave the building.

Heartbeats from application code, CI/CD and serverless

Not every scheduled job is a shell script. Queue workers, scheduled commands in frameworks such as Laravel, Rails or Django, Node.js or Python schedulers, Kubernetes CronJobs, serverless functions on a timer and nightly CI/CD pipelines can all send a heartbeat with one HTTP request from their own code. Use the language’s standard HTTP client, send the ping after the work is committed, and do not let a failed ping crash the job itself.

Some services also support start and failure signals: one request when the job starts, another when it finishes or fails. That allows the monitor to measure run duration and to alert both on jobs that never start and on jobs that start but never finish – a typical symptom of a hanging dependency.

Monitoring intranet devices and internet connections

Because the device reaches out to the monitor and not the other way round, heartbeat monitoring works behind firewalls and NAT, without a public IP address and without opening any inbound port. That makes it a good fit for office servers, internal tools, NAS systems, Raspberry Pi projects, IoT gateways and devices at remote sites.

A small cron job that sends a heartbeat every five minutes turns any such device into a monitored one. If the internet connection drops, the power fails or the device freezes, the pings stop and the alert tells you. The same trick monitors the internet connection of a branch office or the power status of critical equipment: as long as the device can make outbound HTTP requests, it can report that it is alive.

What a heartbeat monitor tracks

A heartbeat monitor records whether each expected ping arrived in time. From that it derives the up or down status, the time of the last received heartbeat, an uptime percentage over time and an incident history with the start and end of every missed-job event. With start signals, the run duration is added, which shows slowly growing jobs before they collide with the next run.

The time of the last heartbeat is the most useful number in daily work: “last successful backup: 7 hours ago” answers the question an incident review will ask, and it answers it before the incident.

Best practices and common mistakes

The most common mistake is pinging on failure – sending the heartbeat whether or not the job succeeded. The second is a grace period that is far too generous, which delays every alert. Others: reusing one ping URL for several jobs, so one healthy job hides another broken one; forgetting to update the interval when the schedule changes; ignoring time zones and daylight saving time, which shift cron schedules twice a year; and sending alerts to an address nobody watches.

Good practice is the mirror image: one monitor per job, the ping as the last step after a success check, an interval that matches the schedule, a tight but realistic grace period, maintenance windows for planned downtime, and a quick test of every new monitor. Treat the ping URLs like secrets – anyone who knows a URL can send false heartbeats.

Notifications, recurring alerts and maintenance windows

A missed heartbeat is rarely as urgent as a website outage, but some are: a failed payment export on billing day, or a sync that feeds the shop with stock levels. Route alerts by importance. Most monitoring services offer email for everything plus faster channels – SMS, voice calls, push notifications or chat and incident tools such as Slack, Microsoft Teams or PagerDuty – for the jobs that cannot wait until the next morning.

Recurring notifications repeat the alert while the job stays missing, so a single overlooked message does not leave a backup gap for a week. Maintenance windows pause the monitor during planned work – a server migration, a database upgrade, a holiday freeze – so that jobs you stopped on purpose do not page anyone. And when several people share responsibility, team access with read, write or notify-only roles keeps everyone informed without giving everyone the power to delete monitors.

Choosing a cron job monitoring tool

Dedicated cron monitoring services, general uptime services with a heartbeat monitor type and self-hosted options all exist. Compare them on the shortest and longest supported interval, whether grace periods and start/fail signals are available, how alerts are delivered – email, SMS, voice, chat, incident tools – whether recurring notifications and maintenance windows are included, how many heartbeat monitors the plan allows and how long history is kept. For a handful of jobs, a free tier is often enough; dozens of production jobs justify a plan with team access and better alerting.

Where monitordefend fits

monitordefend does not receive heartbeats and does not monitor cron jobs. It monitors websites from the outside: uptime every five minutes, response time, broken links, sitemap and Google indexing, checkout pages and suspicious changes, with email alerts. Its free cron expression generator explains a schedule and lists the next run times; for the heartbeat itself, use a dedicated cron monitoring tool.

Frequently asked questions

What is cron job monitoring and how does it work?

Cron job monitoring, also called heartbeat monitoring, checks whether scheduled tasks run on time. The job sends a request to a unique monitoring URL when it finishes; if the request does not arrive within the expected interval plus a grace period, the monitor sends an alert.

What is a cron job?

A task that a scheduler starts automatically at set times or intervals, for example a nightly backup. The term comes from the Unix cron scheduler; Windows uses Task Scheduler for the same purpose.

What kinds of tasks should I monitor?

Anything whose failure for a day would hurt: backups, billing runs, data syncs, certificate renewals, email sending jobs, report generation, cache rebuilds and cleanup scripts.

What is the difference between cron job monitoring and other monitor types?

Website, ping, port and keyword monitors send requests to your service and check whether it is reachable. Cron job monitoring works in reverse: your task calls the monitor, which confirms that the task actually ran.

Can I use cron job monitoring for intranet devices?

Yes. The device only needs outbound HTTP access, so it can send heartbeats from behind a firewall or NAT without a public IP. If the device, its power or its internet connection fails, the pings stop and you are alerted.

How do I send requests to the heartbeat URL?

With a GET or POST request at the end of the job – curl or wget in crontab, Invoke-RestMethod in PowerShell, or the HTTP client of your application code, CI pipeline or serverless function. Send it only after the job succeeded.

How long can the monitoring interval be?

Typical services support intervals from one minute up to about a month, plus a grace period. Match the interval to the job’s schedule and keep the grace period just above the slowest normal run.

What does a heartbeat monitor track?

Whether each expected ping arrived on time, the up or down status, the time of the last heartbeat, uptime percentage and an incident history of missed runs – and, with start signals, the run duration.

Does monitordefend offer cron job monitoring?

No. monitordefend monitors websites and sends email alerts; it does not receive heartbeats. Its free cron expression generator helps you check a schedule.

Related pages

• Cron expression generator & explainer
• Best Cronitor Alternatives for Cron Monitoring and Status Pages (2026)
• Incident management for monitoring: track, filter and resolve outages
• IT alerting software: get instant alerts for critical incidents
• The All-in-One Website Monitoring Tool