Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I prefer to stick scheduled tasks in /etc/crontab so I can see at a glance what's scheduled to run, regardless of which user the task runs as.

The only gotcha is that the format isn't validated on save, unlike crontab -e -- so a stray character can quietly break the entire cron.

Is there a way to validate the /etc/crontab format before/after save?

share|improve this question
If, like me, you came here looking for a simple (non-scriptable) way to tell you whether you'd got your cron entry right, you might be interested in — it's an online validator for cron entries with human-friendly output. – Matt Gibson Dec 20 '14 at 11:18
up vote -3 down vote accepted

This has already been answered over on Stack Overflow.

share|improve this answer
It should be noted that the answer on Stack Overflow was specifically solving the question with PHP, which may or may not be useful for some people. – Dave Wongillies Aug 30 '13 at 2:17
not the kind of answer I was looking for.. perhaps something which is not specific to php.. anything but a library.. – Gaurav Agarwal Jan 13 '14 at 8:41
Totally unrelated. – matteo Feb 13 at 23:25

Wicked cool shell scripts by Dave Taylor has a shell script that validates crontab files.

You can get the script at the site for the books: verifycron.
Thanks to seth for the hint.

share|improve this answer
Source is on the site for the book as well: Really like that book. – seth Jul 21 '09 at 19:58
@seth: Added the link to the answer, thanks. – Ludwig Weinzierl Jul 21 '09 at 20:18

Another more recent solution is the python script chkcrontab

share|improve this answer
It doesn't check users' cronjobs yet – userlond Oct 19 '15 at 7:22

The only reliable way I found is to check the log.

cron checks /etc/crontab every minute, and logs a message indicating that it has reloaded it, or that it found an error.

So after editing, run this:

sleep 60; grep crontab /var/log/syslog | tail

Example output with an error:

Jan  9 19:10:57 r530a cron[107258]: Error: bad minute; while reading /etc/crontab
Jan  9 19:10:57 r530a cron[107258]: (*system*) ERROR (Syntax error, this crontab file will be ignored)

Good output:

Jan  9 19:19:01 r530a cron[107258]: (*system*) RELOAD (/etc/crontab)

That's on Debian 8. On other systems, cron might log to a different file.

(I thought I could avoid hunting for the right log file by using systemd's journalctl -u cron, but that didn't show me these log entries, and actually seems to have stopped logging cron events 2 days ago for some reason)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.