---
title: "Cron job monitoring that alerts on silence | Logdash"
description: "How cron job monitoring works, why one ping per run is not enough on Logdash, the three heartbeat patterns that are, and when Healthchecks.io fits better."
url: https://logdash.io/cron-monitoring
---

# Cron job monitoring

Cron job monitoring means every successful run proves itself to a service outside your servers, and that service alerts you when the proof stops arriving, because a job that never started logs no error anywhere.

A cron job that fails loudly is the easy case. The expensive one is the job that stops running: the crontab that did not survive a server rebuild, the scheduler container a deploy replaced, the workflow GitHub disabled after 60 quiet days in a public repo. Nothing ran, so nothing threw, nothing reached the error tracker, and cron mailed its output to a local root mailbox nobody reads.

## What a cron monitor has to get right

Flip the direction. Instead of waiting for an error, have the job report in after every good run, and treat silence as the failure. Three rules keep the report honest. Send it after the work, not before, so a run that dies halfway stays silent. Chain it behind &&, so a non-zero exit never counts as success. And keep the timer on a service outside your infrastructure, because a monitor on the same box dies with it.

## How Logdash watches a job

Logdash does this with push monitors. Push monitors are on the Pro plan, $15 a month, one per service and up to 50 services. Each one is checked every 15 seconds. A ping inside the window keeps it up, an empty window flips it to down and sends the alert, and the next ping flips it back and sends another. There is no per-job schedule and no grace setting. So a nightly job that pings once when it finishes reads as down 15 to 30 seconds later and stays down all day. Every guide here uses one of three patterns that fit the model instead:

- Workers that never stop, like Celery, Sidekiq and BullMQ. Schedule a canary job every 5 to 10 seconds that pings. It only arrives if the scheduler, the broker and a worker all still work.
- Jobs on a schedule, like crontab, pg\_cron, the Laravel scheduler, Kubernetes CronJobs and Windows Task Scheduler. The job leaves a stamp when it succeeds, and a heartbeat pings every 5 to 10 seconds while the stamp is younger than the schedule plus the lateness you accept.
- The free plan, or a runner that cannot loop, like GitHub Actions. The job tells your app, the app keeps a key that expires, and an HTTP monitor checks a route that returns 503 once the key is gone. HTTP monitors run on every plan, every 5 minutes on the free one.

## Test the ping URL first

 Run it once by hand 

```bash
# A push monitor takes a plain POST. No auth header, no body.
curl -fsS -o /dev/null -w '%{http_code}\n' -X POST \
  https://api.logdash.io/ping/68b4c1f0e3a2d5c7b9f01234

# 201  the ping counts for the current 15-second window
# 404  no push monitor has that id, and curl -f exits non-zero
# 429  more than 300 pings a minute from one IP
```

1. **Create a push monitor** On Pro, add a service named after the job, set its monitor to push and copy the ping URL. The name is what the alert will say.
2. **Wire up the heartbeat** Pick the guide for your runner below and paste its snippet. The monitor goes up within 15 seconds of the first ping.
3. **Break it on purpose** Connect a Telegram channel, then stop the heartbeat. Within 30 seconds of the last ping Telegram shows the job's name, is down, status code 0 and Did not receive call for this time range. Start it again and the is up message follows.

## Picking a cron job monitoring tool

### Logdash vs Healthchecks.io for cron jobs

| Feature                     | Logdash                                 | Healthchecks.io                                          |
| --------------------------- | --------------------------------------- | -------------------------------------------------------- |
| Schedule per job            | None, the heartbeat pattern carries it  | Period or cron expression, time zone and grace per check |
| Signals from the job        | Ping, and silence as the failure        | Ping, start, fail and exit status                        |
| Host goes dark              | Alert within 30 seconds                 | Alert after the period plus grace                        |
| HTTP uptime checks and logs | Same account, eight SDKs                | Heartbeats only                                          |
| Alert channels              | Telegram and webhook                    | Email, Slack, Telegram, webhooks and more                |
| Free plan                   | No push monitors, Pro is $15 a month    | 20 checks                                                |
| Self-hosting                | AGPL-3.0, not a one-command install yet | BSD-3-Clause, self-hostable today                        |

### When Healthchecks.io is the better pick

- Your jobs only need one ping per run on a known schedule, and you would rather type a cron expression than run a heartbeat next to each job.
- You want to see a run start, fail and finish, not only whether the last good one is recent.
- You want email or Slack alerts without building a bridge behind a webhook.
- You are not on Pro, or you want to run the monitor on your own server.

### Is there cron job monitoring free of charge? 

Yes. Healthchecks.io watches 20 jobs free, Cronitor 5 monitors and Dead Man's Snitch one. Logdash push monitors start at Pro, $15 a month, but the freshness-route pattern runs on free HTTP monitors: five services, checked every 5 minutes.

### Is there open source cron job monitoring? 

Healthchecks.io is BSD-3-Clause licensed and the hosted service runs the same code. Logdash is AGPL-3.0 with the full source on GitHub. Cronitor is closed source with open-source SDKs.

### Can cron job monitoring be self hosted? 

Healthchecks.io can, today, from the same repository as the hosted service. Logdash cannot yet: it runs locally for development, and production self-hosting is open work, not a one-command install. If self hosted is a hard requirement, use Healthchecks.io.

### What is the best cron job monitoring tool? 

For many jobs on fixed schedules, Healthchecks.io or Cronitor, which apply the schedule and grace for you. For alerts by email with nothing else, Dead Man's Snitch. For jobs plus uptime checks and logs on one timeline, with Telegram alerts, Logdash on Pro.

### What does a cron job monitoring service do? 

It holds the timer your job cannot hold for itself. The job checks in, the service notices when a check-in is late and alerts you. It has to run outside your infrastructure, or a dead server takes the monitor down with the job.

## All cron monitoring guides

[Scheduled task monitoring](https://logdash.io/cron-monitoring/scheduled-tasks): Scheduled task monitoring means the task leaves proof after every clean run, whatever scheduler starts it, and a service outside the box alerts you when that proof gets older than the schedule allows.

[Dead man's switch monitoring](https://logdash.io/cron-monitoring/dead-mans-switch): A dead man's switch alerts on the absence of a signal: the job checks in after every successful run, and when the check-ins stop, for any reason at all, the switch fires.

[Backup monitoring](https://logdash.io/cron-monitoring/backup-monitoring): Backup monitoring means hearing about a backup that did not finish, and AWS Backup and Azure Backup already alert on their own jobs, so the gap is the pg\_dump, restic and rsync scripts nothing watches.

[Restic backup monitoring](https://logdash.io/cron-monitoring/restic-backup): Chain restic backup, restic check and a timestamp so the stamp only moves when both commands exit 0, then let a heartbeat ping Logdash while the stamp is under 26 hours old, and a failed, partial or skipped backup becomes a Telegram alert.

[pg\_cron monitoring](https://logdash.io/cron-monitoring/pg-cron): pg\_cron writes every run to cron.job\_run\_details and never alerts on it, so monitor it with a second pg\_cron job that pings an external monitor every 10 seconds, but only while the last finished run of your job succeeded inside the window you expect.

[Laravel scheduler monitoring](https://logdash.io/cron-monitoring/laravel-scheduler): Add a 10-second heartbeat task that posts to an external monitor only while your job last succeeded within a set window, so one alert covers both a failed task and a scheduler that is not running at all.

[Celery beat monitoring](https://logdash.io/cron-monitoring/celery-beat): Have beat send a canary task every 10 seconds that posts to a Logdash push monitor, and the first 15 seconds without a ping tells you beat, the broker or every worker has stopped.

[Sidekiq monitoring](https://logdash.io/cron-monitoring/sidekiq): The Sidekiq Web UI shows queues, retries and dead jobs while you look at it; to be told when Sidekiq stops processing, run a canary job every 5 seconds that pings a Logdash push monitor.

[BullMQ monitoring](https://logdash.io/cron-monitoring/bullmq): Use Bull Board or Taskforce.sh to see queues and jobs, and add a 10-second job scheduler that pings a Logdash push monitor so you are told when workers stop processing.

[Kubernetes CronJob monitoring](https://logdash.io/cron-monitoring/kubernetes-cronjob): Kubernetes records when each CronJob last succeeded in status.lastSuccessfulTime and never alerts on it, so either alert on that timestamp in Prometheus through kube-state-metrics, or run a small watcher that pings an external monitor every 10 seconds while it is fresh.

[GitHub Actions monitoring](https://logdash.io/cron-monitoring/github-actions): GitHub shows you the runs that failed but never the runs that did not start, so watch a scheduled workflow from outside: the last step reports success, and a monitor alerts you when that report goes stale.

[Windows Task Scheduler monitoring](https://logdash.io/cron-monitoring/windows-task-scheduler): Task Scheduler keeps each task's last run time and last run result but never alerts on them, so monitor it with a small PowerShell watcher that pings an external monitor every 10 seconds while the last run is recent and clean.