Crontab Monitoring: How to Catch Silent Cron Failures

Why Crontab Can't Monitor Itself

Crontab runs the command you give it and walks away. It doesn't check whether the script exited cleanly, whether an API call timed out, or whether the process crashed halfway through. There's no dashboard, no history, no built-in concept of "healthy" versus "broken." Cron job failures are silent by design — the daemon's job is to execute, not to verify.

This is why teams discover failures only after the downstream damage is visible: a report never generated, a backup that hasn't run in three weeks, a stale cache nobody refreshed. Crontab monitoring exists to fill that gap — adding the visibility layer cron was never built to provide. The rest of this article walks through the three practical ways to build that layer, whatever your stack looks like.

3 Ways to Actually Monitor Crontab Jobs

There are really only three mechanisms to monitor crontab jobs, and most crontab job monitoring tools are built on some combination of them:

1. Log-based monitoring — reading what cron and your scripts already write down.
2. Exit code and wrapper scripts — capturing success/failure at the moment the job runs.
3. Push/heartbeat monitoring — having the job report in, and getting alerted when it doesn't.

Each catches a different slice of failure. Understanding the tradeoffs is what lets you pick — or combine — the right ones instead of guessing.

1. Log-Based Monitoring

The traditional approach is checking cron logs directly — typically /var/log/cron on RHEL-based systems, or the cron facility inside syslog on Debian/Ubuntu. These logs confirm cron fired the job at the scheduled time, and crontab's MAILTO variable can, in theory, email you any output the command produced.

In practice, crontab log monitoring has two problems. First, it's reactive — someone has to go looking, usually after something has already broken downstream. Second, MAILTO frequently doesn't work at all, because most servers don't have a mail transfer agent configured. Cron tries to send the email, silently fails to deliver it, and the notification path is dead without anyone realizing it. Cron logs also only tell you the job started; they say nothing about whether it finished successfully. For daemon-level detail on why this happens, see how the cron daemon really works.

2. Exit Code and Wrapper Script Checks

A more direct method is checking the job's exit code from within the job itself. Wrap the actual command in a small script that captures $? after execution, then branches: on a non-zero exit code, hit a webhook, send a Slack message, or write to an alert log. This answers "did the cron job run successfully?" far more precisely than logs alone, because it checks the process's own reported outcome rather than inferring it after the fact.

Crontab exit code monitoring is a solid step up, but it carries a maintenance cost. Every cron entry needs its own wrapper, every wrapper needs to be kept consistent, and someone has to maintain the alerting logic across all of them. It also has a blind spot: if the job never starts — because cron itself is misconfigured, the server rebooted, or the schedule got wiped — there's no exit code to check, because there's no execution to check it on.

3. Push/Heartbeat Monitoring

Push or heartbeat monitoring flips the model. Instead of watching for a job to fail, you watch for it to check in — a dead man's switch. The job pings a unique URL when it completes successfully; a monitoring service tracks the expected schedule, and if the ping doesn't arrive within a grace period, it alerts you.

This is the only method of the three that reliably catches jobs that don't run at all — a disabled cron entry, a server outage, a scheduler that silently stopped. Cron job heartbeat monitoring needs no log parsing, no MTA, no per-job alerting code beyond a single curl call appended to the command. It shifts responsibility for "did this happen on time" onto infrastructure built for that purpose. For a deeper technical comparison of pull-based checks versus push and heartbeat models, see how healthcheck systems work.

What to Track: The Metrics That Actually Matter

Regardless of which method (or combination) you use, effective crontab monitoring comes down to a small set of concrete signals:

• Last run timestamp — when the job last actually executed, not just when it was scheduled to.
• Run duration — how long execution took; a sudden jump often signals trouble before an outright failure does.
• Exit status — whether the process reported success or failure.
• Expected next run — the schedule cron should follow, used as the baseline for comparison.
• Grace period / threshold window — how much lateness is tolerable before a missed check-in counts as a real cron job grace period violation and triggers an alert.

That last one matters more than it looks. Jobs rarely run at the exact second scheduled — server load, queueing, and network latency all add variance. A grace period lets you absorb normal jitter without missing real failures or drowning in false alarms. Tracked together, these five metrics tell you far more than any single number in isolation — last run time alone can't tell you if the job is slower than usual, and duration alone can't tell you if it's overdue.

Setting Up Crontab Monitoring in Minutes

Building the DIY version of this — log parsing, a wrapper script per job, a place to store run history, an alerting integration — is a multi-day project even for a handful of jobs, and it grows every time you add a new one. A purpose-built tool is faster because the tracking, grace periods, and alerting are already built; you're just wiring your job into them.

With Cronevra, the process is:

1. Create a monitor for the job and get a unique ping URL.
2. Append the ping to your existing crontab command, so it fires on success — for example: */15 * * * * /path/to/script.sh && curl -fsS https://cronevra.com/ping/your-id
3. Set the expected schedule and grace period so Cronevra knows when to expect the next check-in.
4. Get alerted the moment a ping is late or missing — no server-side logging or wrapper maintenance required.

That's the entire setup — no MTA to configure, no log files to tail, no per-job alerting logic to write and maintain. If you're still weighing whether a dedicated cron job monitoring tool is worth it versus rolling your own, this guide to choosing a cron monitor walks through the decision in more depth.

Skip the DIY Maintenance

Log parsing and wrapper scripts work, but they're one more system to maintain, and they still miss jobs that never run at all. Wiring your crontab entries into heartbeat pings takes minutes per job and catches the failures the other two methods can't. Try Cronevra and check the pricing page to see which plan fits your job count.

Frequently Asked Questions

How do I know if my crontab job failed silently?

You won't know from crontab itself — it has no built-in success/failure reporting. The only reliable ways are checking exit codes via a wrapper script, reviewing cron logs after the fact, or using heartbeat monitoring, which is the only method that also catches jobs that never ran at all.

Can I monitor crontab jobs without installing any extra software?

Yes, to a limited extent — you can check /var/log/cron or syslog and rely on crontab's MAILTO variable for email alerts. But MAILTO often fails silently because most servers lack a configured mail transfer agent, and log checking requires someone to actively go looking rather than being alerted automatically.

What's the difference between checking cron logs and real crontab monitoring?

Cron logs confirm a job started at the scheduled time but say nothing about whether it finished successfully. Real crontab monitoring tracks exit status, run duration, and whether the job checked in on schedule, giving you proactive alerts instead of a log file you have to search after something has already gone wrong.

Does crontab send email alerts when a job fails?

Only if MAILTO is set and a working mail transfer agent is installed on the server, which is often not the case on modern cloud instances and containers. When no MTA is configured, cron attempts delivery, fails silently, and no alert ever reaches you.

How do I monitor a cron job's exit code?

Wrap the actual command in a script that captures $? after execution and branches based on the result — sending a webhook or notification on a non-zero exit code. This tells you whether the process itself reported success, though it won't catch cases where the job never ran in the first place.

What is a dead man's switch for cron jobs?

It's a monitoring pattern where the job pings a monitoring URL on successful completion, and the monitoring service alerts you if that ping doesn't arrive within an expected window. It's the only method that reliably catches jobs that fail to run at all, not just jobs that run and then fail.