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
# 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- 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.
- 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.
- 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.