Why do cron jobs fail silently?

Cron only starts a job; it does not check the result. If the script errors, times out or returns a non-2xx status, cron writes to local mail or a log you may never read, so the failure goes unnoticed.

How do I get an alert when a cron job fails?

Either add error handling and alerting inside every script, use a dead-man-switch service the job pings on success, or run the job from a hosted cron service that checks the response and emails you on failure.

What is a dead man switch for cron?

A dead man switch expects a regular ping from your job. If the ping stops arriving within the expected window, the service alerts you — catching failures where the job never ran at all.

Guide

How to monitor cron jobs

Cron will happily start a broken job every night for a year and never mention it. Here's why that happens, and the practical ways to find out the moment something breaks.

Why cron jobs fail silently

Cron's job is to start your command at the right time. That's all. It does not inspect exit codes, response bodies or HTTP statuses in any way you'd notice.

When something goes wrong, the output typically goes to local system mail or a log file on the server — a place most people never look. So all of these look identical from the outside:

The script ran and worked.
The script ran and threw a fatal error on line 3.
The endpoint returned 500 for the last six weeks.
The job never ran at all, because the crontab was wiped in a server migration.

The classic version of this story: a nightly database backup that has been failing since a path changed — discovered on the day someone needs to restore it.

What "monitoring" actually needs to cover

Failure mode	What you need to detect it
The job errored	Check the exit code or HTTP status of every run.
The job hung	A timeout, so a run that never finishes is treated as a failure.
The job never started	An expectation of when it should have run (a dead man switch).
The job got slow	Response-time history, so you see degradation before an outage.
It recovered	A follow-up notice, so you know it's fixed without checking manually.

Option 1 — roll it yourself in each script

Wrap the work in error handling and send yourself an email or Slack message on failure.

Trade-off: it works, but you repeat it in every script, and it can't catch the case where the job never ran — a dead script sends no alerts.

Option 2 — MAILTO in the crontab

Setting MAILTO=you@example.com makes cron email you any output a job produces.

Trade-off: it depends on working mail on the server, floods you with output from healthy jobs, and still says nothing when cron itself stops running.

Option 3 — a dead man switch

Your job pings a URL each time it succeeds. If the ping doesn't arrive in the expected window, you get alerted.

Trade-off: excellent at catching "it never ran", but you still have to modify every script to send the ping.

Option 4 — run the job from a hosted cron service

Instead of your server triggering the work and hoping, the service calls your URL or webhook on schedule and evaluates the result: status code, response time, timeouts and retries — then alerts you when it breaks.

Because the scheduler lives outside your server, it also catches the failure mode the others miss: your machine being down entirely.

A sensible default setup

Expose the task behind an authenticated URL or webhook.
Schedule it with a service that records every run.
Set a timeout that reflects how long the job should really take.
Add 1–3 retries so a transient blip doesn't page you at 3am.
Turn on failure alerts — and make sure you also get a recovery notice.

This is exactly what cronjobs.live does.
We run your schedule, check the result of every execution, keep the logs and response times, retry transient failures, and email you the instant a job breaks — plus a recovery email once it's healthy again. Free, unlimited jobs, no credit card.

Start monitoring free