Crontab – The most powerful Linux Scheduler

Crontab is a Linux based utility for scheduling time-based jobs that run automatically at a set time, date or after a specific interval. You can automate various repetitive administrative tasks (e.g. database backups, email reminders, etc) using cron jobs.

The beauty of cron job lies in accuracy. Since the overall process of running the tasks is automated, you can use this utility to execute mission critical instructions without ever forgetting.

Although there are many centralized job scheduler available in market, crontab is still the most powerfull & inbuilt tool available for Linux environment.

Crontab is a list of commands that you want to run on a regular schedule, and also the name of the command used to manage that list.

The word Crontab stands for “cron table” because it uses the job scheduler cron to execute tasks. Cron itself is named after “Chronos, ” the Greek word for time.

Linux Crontab Format
minute : You can specify a number between 0 and 59 hour      :  Depending on what you want to automate, you can use a value between 0 and 23. day of month    : The third value represents the day of the month from 1–31. Use of this value is very practical in mission critical applications. month   : You can explicitly instruct cron to run only on specific months. The accepted range is 1–12. day of the week : In a production environment, there are number of scenarios that may require a cron job to run at specific days of the week. /path/to/ : Full path of the script / command to be run at the set time.
Usage Tips & Tricks
  • * can be used for all Value in any field
  • */5 in minute field means every 5 minutes (application to other Fields also)
  • 0-10/2 in minute field mean every 2 minutes in the first 10 minute. (application to other Fields also)
  • mon, tue, wed, ….. can use used as values for the day of the week field.
  • jan, feb, mar, ….. can be used as values for the month field.
Special keywords and its meaning
Keyword    Equivalent
@yearly    0 0 1 1 *
@daily     0 0 * * *
@hourly    0 * * * *
@reboot    Run at startup.
Important configuration Files
Important corntab files are located in /var/spool/ (or a sub-directory such as /var/spool/cron/crontabs), but they are not intended to be edited directly. Instead, they are edited by running crontab. Cron jobs can be allowed or disallowed for individual users, as defined in the files /etc/cron.allow and /etc/cron.deny.
Command usage

Edit your crontab

crontab -e

Display (“list”) the contents of your crontab.

crontab -l

Remove your crontab, effectively un-scheduling all crontab jobs.

crontab -r

Edit the crontab of the user named mike.

sudo crontab -u mike -e

The -u option requires administrator privileges, so the command is executed using sudo.

View the crontab of user sandy.

sudo crontab -l -u sandy
To schedule a job for every minute using Cron.

Ideally you may not have a requirement to schedule a job every minute. But understanding this example will will help you understand the other examples.

* * * * * CMD

The * means all the possible unit — i.e every minute of every hour through out the year.

Schedule a job for more than one time (e.g. Twice a Day)

The following script take a incremental backup twice a day every day.

This example executes the specified incremental backup shell script (incremental-backup) at 11:00 and 16:00 on every day. The comma separated value in a field specifies that the command needs to be executed in all the mentioned time.

00 11, 16 * * * /home/maverick/bin/incremental-backup

  00 – 0th Minute (Top of the hour)
  11, 16 – 11 AM and 4 PM
  * – Every day
  * – Every month
  * – Every day of the week

To schedule a job for certain range of time (e.g. Only on Weekdays)

If you wanted a job to be scheduled for every hour with in a specific range of time then use the following.

  •     Cron Job everyday during working hours :

    This example checks the status of the database everyday (including weekends) during the working hours 9 a.m – 6 p.m

    00 09-18 * * * /home/maverick/bin/check-db-status

    00 – 0th Minute (Top of the hour)
    09-18 – 9 am, 10 am, 11 am, 12 am, 1 pm, 2 pm, 3 pm, 4 pm, 5 pm, 6 pm
    * – Every day
    * – Every month
    * – Every day of the week

  •     Cron Job every weekday during working hours :

    This example checks the status of the database every weekday (i.e excluding Sat and Sun) during the working hours 9 a.m – 6 p.m.

    00 09-18 * * 1-5 /home/maverick/bin/check-db-status

    00 – 0th Minute (Top of the hour)
    09-18 – 9 am, 10 am, 11 am, 12 am, 1 pm, 2 pm, 3 pm, 4 pm, 5 pm, 6 pm
    * – Every day
    * – Every month
    1-5 -Mon, Tue, Wed, Thu and Fri (Every Weekday)

Schedule a background Cron job for every 10 minutes.

Use the following, if you want to check the disk space every 10 minutes.

*/10 * * * * /home/maverick/check-disk-space

It executes the specified command check-disk-space every 10 minutes through out the year.

Debugging cron commands
Check the mail!

By default cron will mail any output from the command to the user it is running the command as. If there is no output there will be no mail. If you want cron to send mail to a different account then you can set the MAILTO environment variable in the crontab file e.g.

1 2 * * * /path/to/your/command
Capture the output yourself

You can redirect stdout and stderr to a file. The exact syntax for capturing output may vary depending on what shell cron is using. Here are two examples which save all output to a file at /tmp/mycommand.log:

1 2 * * * /path/to/your/command &>/tmp/mycommand.log
1 2 * * * /path/to/your/command >/tmp/mycommand.log 2>&1
Look at the logs

Cron logs its actions via syslog, which (depending on your setup) often go to /var/log/cron or /var/log/syslog.

If required you can filter the cron statements with e.g.

grep CRON /var/log/syslog

Now that we’ve gone over the basics of cron, where the files are and how to use them let’s look at some common problems.

Check that cron is running

If cron isn’t running then your commands won’t be scheduled …

ps -ef | grep cron | grep -v grep

should get you something like

root    1224   1  0 Nov16 ?    00:00:03 cron


root    2018   1  0 Nov14 ?    00:00:06 crond

If not restart it

/sbin/service cron start


/sbin/service crond start

There may be other methods; use what your distro provides.

Cron runs your command in a restricted environment.

What environment variables are available is likely to be very limited. Typically, you’ll only get a few variables defined, such as $LOGNAME, $HOME, and $PATH.

Of particular note is the PATH is restricted to /bin:/usr/bin. The vast majority of “my cron script doesn’t work” problems are caused by this restrictive path. If your command is in a different location you can solve this in a couple of ways:

    Provide the full path to your command.

    1 2 * * * /path/to/your/command

    Provide a suitable PATH in the crontab file

    1 2 * * * command

If your command requires other environment variables you can define them in the crontab file too.

Check the crontab format

You can’t use a user crontab formatted crontab for /etc/crontab or the fragments in /etc/cron.d and vice versa.

A user formatted crontab does not include a username in the 6th position of a row, while a system formatted crontab includes the username and runs the command as that user.

I put a file in /etc/cron.{hourly,daily,weekly,monthly} and it doesn’t run

  •  Check that the filename doesn’t have an extension see run-parts
  •  Ensure the file has execute permissions
  •  Tell the system what to use when executing your script (eg. put #!/bin/sh at top)
Cron date related bugs

If your date is recently changed by a user or system update, timezone or other, then crontab will start behaving erratically and exhibit bizarre bugs, sometimes working, sometimes not.

This is crontab’s attempt to try to “do what you want” when the time changes out from underneath it. The “minute” field will become ineffective after the hour is changed. In this scenario, only asterisks would be accepted.

Restart cron and try it again without connecting to the internet (so the date doesn’t have a chance to reset to one of the time servers).

Percent signs, again

To emphasise the advice about percent signs, here’s an example of what cron does with them:

# cron entry
* * * * * cat >$HOME/cron.out%foo%bar%baz

will create the ~/cron.out file containing the 3 lines


This is particularly intrusive when using the date command. Be sure to escape the percent signs

* * * * * /path/to/command --day "$(date "+\%Y\%m\%d")"
Limitation of Crontab

 Although crontab is a very accurate process scheduler used in linux servers, it lacks the most basic functionality of reporting a failure.

Any failure to run a script is usually identified at a much later date & it requires quiet extensive troubleshooting to fix it.

The best option to fix the monitoring of crontab can achieved by using  a monitoring and scheduling option by  Cronitor.

Still it’s a very accurate & robust process scheduler used in linux servers.

Leave a Reply

Your email address will not be published. Required fields are marked *