How to Check Cron: The 4-Layer Verification Checklist

Checking Cron Isn't One Check — It's Four

When a scheduled job seems to have gone missing, the instinct is to run one command — crontab -l, maybe a grep through a log file — and call it verified. That instinct is the problem. Cron can fail at four completely different layers, and a single check only ever tells you about one of them.

To really check cron, confirm four things: the cron daemon is alive, the job is scheduled the way you think it is, the job ran and finished successfully, and — the layer almost everyone skips — that something would actually tell you if any of the first three ever silently broke. This piece walks through all four, with exact commands and where to go for deeper detail.

1. Is the Cron Daemon Even Running?

Before worrying about a specific job, confirm cron itself is alive. If the daemon is dead, every job on the box is silently skipped, and nothing in your crontab file matters.

On most Linux distributions, ask systemd:

systemctl status cron

or, on Red Hat–based systems:

systemctl status crond

Look for active (running). If it says inactive or failed, restart it with systemctl restart cron and check what killed it — a bad config or resource limit is the usual culprit.

On macOS, there's no crond — scheduled tasks run through launchd. Check a specific agent or daemon with:

launchctl list | grep 

A missing entry means launchd never loaded that job at all, which is a different failure mode from a job loading but failing to fire.

2. Is the Job Actually Scheduled?

With the daemon confirmed alive, check whether your specific job is registered correctly:

crontab -l

This lists the crontab for the current user — and that's where most people get tripped up. If you're checking as one user but the job was installed under another (say, www-data or root), crontab -l shows nothing, and it's easy to conclude the job vanished when it's simply filed under a different account. Run sudo crontab -l -u to check another user's table, and don't forget system-wide jobs in /etc/cron.d/, /etc/crontab, or /etc/cron.{daily,weekly,monthly} — none of which show up in a per-user crontab -l.

This step is also where syntax errors hide: five fields isn't the same as six, and day-of-week versus day-of-month mistakes are common. For a full breakdown of verifying entries, see Check Crontab: The Full Verification Workflow. For every listing option and flag, Show Crontab Jobs: The Complete Command Reference covers it in full, and for checking schedules across multiple users or containers, Crontab View Jobs: How to See Cron Tasks in Any Context is the deeper reference.

3. Did the Job Run — and Did It Succeed?

Being scheduled correctly doesn't mean the job executed, and executing doesn't mean it succeeded. Confirming cron is installed is not the same as confirming your backup script finished without error last night.

Start with system logs. On Debian/Ubuntu, cron activity typically lands in /var/log/syslog; on other distributions, check /var/log/cron or a dedicated cron.log. Grep for your job's command or the CRON tag:

grep CRON /var/log/syslog

Firing isn't the same as succeeding. Check the exit code — cron often mails output to the crontab owner if MAILTO is set, and a nonzero exit code means the job ran but failed partway through. Reviewing that output is the only way to know whether execution completed cleanly. For log formats, locations, and interpretation across distributions, see Healthchecks for Cron Jobs: How They Work and Their Limits.

4. The Check Cron Can't Do On Its Own

None of the three checks above run themselves. Someone has to SSH in, run systemctl status cron, list the crontab, and grep the logs — every time they want to know if a job is healthy. That works fine the first week after deployment. It stops working the moment nobody's watching, which is most nights and weekends.

This is exactly how cron jobs fail silently in production. The daemon can die at 2am, a job can quietly stop being scheduled after a deploy overwrites a crontab, or a script can start throwing errors after an upstream API changes — and nothing surfaces any of it unless a human goes looking. Manual checking doesn't scale past a handful of jobs, and it cannot catch a failure that happens while everyone's asleep. This gap is the real reason cron job monitoring exists as its own category of tooling.

Automating the Check: Ping-Based Monitoring

The fix isn't a better manual command — it's removing the human from the loop entirely. Ping-based monitoring has each scheduled job send a small HTTP request to a monitoring endpoint the moment it finishes successfully. If that ping doesn't arrive on schedule — because the job didn't run, the daemon was down, or the script exited with an error — the monitoring service notices the silence and alerts you.

That single design shift covers all three earlier layers at once: no ping means something upstream failed, whether it was the daemon, the schedule, or the execution itself. For a closer look at what a "successful" ping actually confirms and where its limits are, read Ping Health: What It Really Means for Cron Jobs.

This is precisely the gap Cronevra is built to close. Instead of manually checking cron across a fleet of servers, you get automated cron checks running continuously, with alerts the moment a job goes quiet. Compare plans on the Cronevra pricing page to see what fits your team's job count.

Quick Reference Checklist

• Daemon: systemctl status cron (or crond) on Linux; launchctl list | grep on macOS
• Schedule: crontab -l for the current user; sudo crontab -l -u for others; check /etc/cron.d/ and /etc/crontab too
• Execution: grep /var/log/syslog, /var/log/cron, or cron.log for the job; check mailed output and exit codes
• Silent failures: none of the above alert you — set up ping-based monitoring so missed runs trigger notifications automatically

Frequently Asked Questions

How do I check if a cron job actually ran?

Grep your system logs — /var/log/syslog on Debian/Ubuntu or /var/log/cron on other distributions — for the job's command or the CRON tag around the expected run time. If MAILTO is configured, also check the mailed output for the script's exit code, since running and succeeding aren't the same thing.

Why does my cron job work manually but not on schedule?

The most common cause is environment differences — cron runs jobs with a minimal environment and no interactive shell, so PATH variables, working directories, or profile-loaded settings your terminal has may be missing. Hardcode full paths in your script and explicitly set any environment variables the job needs.

How can I check cron logs on Ubuntu or CentOS?

On Ubuntu, cron activity is usually logged to /var/log/syslog; on CentOS and other Red Hat–based systems, check /var/log/cron. Grep either file for your job's command or the CRON tag to confirm execution times and any reported errors.

Is there a command to check cron job history?

Cron itself doesn't retain a dedicated history log — you're relying on whatever's still in /var/log/syslog, /var/log/cron, or cron.log before log rotation clears it. For real history across restarts and rotations, ping-based monitoring services that timestamp each completed run are far more reliable.

How do I check if cron is enabled at boot?

Run systemctl is-enabled cron (or crond) — it should return enabled. If it returns disabled, the daemon won't start automatically after a reboot, so run systemctl enable cron to fix it.

Can I get alerted automatically when a cron job fails instead of checking manually?

Yes — ping-based monitoring has each job send a completion signal to a monitoring endpoint, and the service alerts you if that signal doesn't arrive on schedule. This is exactly the approach Cronevra is built around, replacing manual SSH checks with automatic failure detection.