← Back to blog

Why Your Cron Jobs Are Silently Failing (And How to Catch It)

Cron jobs fail silently by default. Learn how heartbeat monitoring catches failures the moment they happen, before silent failures become emergencies.

The problem with cron

Cron is reliable in one way: it will run your command on schedule. It is unreliable in another way that matters more: it does not tell you when your command fails.

Your server is running. The cron daemon is working. The schedule fires on time. But the script you pointed it at exits with a non-zero status, hits a timeout, or runs out of memory. Nobody knows. Cron’s job is to start the process, not to verify it succeeded.

This is not a cron bug. It is how cron was designed. Cron predates the web. It was built in an era when tasks wrote to log files and a human checked them periodically. That model does not scale to modern infrastructure where one developer manages dozens of scheduled tasks across multiple servers.

What silent cron failures cost you

A silent backup failure means you discover it when you need the backup. Maybe that is three weeks later, after a database corruption incident. The gap between when the backup stopped working and when you needed it is data you cannot recover.

A silent email queue failure means customers stop getting notifications. Password resets, order confirmations, billing receipts. Nobody complains at first because nobody knows what they are missing. By the time you notice, you have thousands of undelivered emails and confused users.

A silent data export failure means your analytics are wrong. Your dashboards show trends based on stale data. You make decisions on incomplete information. The error compounds the longer it goes undetected.

Why uptime monitoring does not catch this

Your uptime monitor says your server is up. Your API returns 200. Your dashboard loads. Everything is fine according to your monitoring dashboard.

But none of those checks tell you whether last night’s backup completed. They do not know if your billing reconciliation ran. They do not know if the data pipeline that populates your analytics finished.

Uptime monitoring answers “can I reach this endpoint?” Heartbeat monitoring answers “did this task run?” They are complementary questions. You need both.

How heartbeat monitoring works

Heartbeat monitoring is simple. Each scheduled task gets a unique URL with a secret token. At the end of your task, add a single line that pings that URL:

curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

If the ping arrives within the expected window, the heartbeat check passes. If the window closes without a ping, the monitor triggers an alert.

You configure the expected interval. If your backup runs every 6 hours, set the interval to 6 hours. Add a grace period if the task duration varies. A 10-minute grace period means the monitor does not alert unless the ping is 10 minutes late.

That is the entire setup. One URL. One curl command. Zero configuration files.

Setting it up in practice

Here is a cron entry for a nightly database backup:

0 2 * * * /usr/local/bin/backup-db.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

The && matters. It means “run curl only if the backup script exits with status 0 (success).” If the backup fails, the curl never runs. No ping arrives. You get an alert.

If you want to monitor that the script ran at all (even if it failed), use ; instead of &&, and add error handling inside the script to report status. But for most use cases, && is what you want. You care about success, not just execution.

What to monitor with heartbeats

Start with the jobs that would hurt most if they silently failed:

Database backups: This is the most common use case and the one with the highest cost of failure. A backup you do not know is missing is worse than no backup at all.

Email delivery queues: If your transactional emails or marketing emails stop sending, you want to know within minutes, not hours.

Billing and invoice generation: Failed billing means lost revenue. A heartbeat on your billing job catches this before the end of the month.

Data syncs and exports: If your analytics pipeline or data warehouse sync fails, your reports are wrong. A heartbeat tells you within the expected interval.

Certificate renewal: If you use certbot or similar tools with auto-renewal, add a heartbeat. Certificate expiry is one of the most preventable causes of downtime.

Log rotation and cleanup: If log rotation fails, your disk fills up. Your server goes down. A heartbeat catches the rotation failure before the disk is full.

Heartbeat monitoring vs. cron monitoring services

Tools like Healthchecks.io and Cronitor focus exclusively on cron and scheduled task monitoring. They do this well. Some add features like job duration tracking and performance trends.

PingWatchdog includes heartbeat monitoring alongside uptime monitoring and SSL monitoring in a single platform. You do not need a separate tool for cron jobs. You monitor your websites, APIs, SSL certificates, and scheduled tasks from one dashboard with one alerting pipeline.

This matters because the same team that monitors uptime usually owns the cron jobs. Consolidating tools means fewer dashboards to check, fewer alert channels to configure, and fewer subscriptions to manage.

Compare PingWatchdog with Healthchecks.io to see how our heartbeat monitoring stacks up alongside uptime monitoring and status pages.

Monitoring cron in containers and Kubernetes

If you run cron jobs inside Docker containers or Kubernetes CronJobs, the same heartbeat pattern works. Add a curl command at the end of your container’s entrypoint or your CronJob’s command.

For Kubernetes:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: your-backup-image
            command:
            - /bin/sh
            - -c
            - "/backup.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN"
          restartPolicy: OnFailure

The same principle applies to AWS Lambda scheduled events, Google Cloud Scheduler, systemd timers, or any other scheduler. If your task can make an HTTP request, it can send a heartbeat.

Get started

PingWatchdog includes heartbeat monitoring on every plan. The Free plan gives you 3 heartbeat monitors. Paid plans go up to 25.

Learn more about heartbeat monitoring features or set up your first monitor.