While the syntax may initially seem confusing, it is actually not that hard to understand but extremely flexible:

Wow, that was easy! If this were really the case, then yes. However, what we described above as <timestamp> is actually composed of five different fields, which make up the combined period for running jobs multiple times. In reality, the timestamp is defined as follows (in order):

1. Minute-of-the-hour
2. Hour-of-the-day
3. Day-of-the-month
4. Month
5. Day-of-the-week

In any of these values, we can substitute a number for a wildcard, which indicates all values. Look at the following table to get a feeling about how we combine these five fields for precise times:

You might be a little confused by this syntax. Since many of us normally write time as 18:30, reversing the minutes and the hour seems a little counter intuitive. However, this is just the way it is (and trust us, you will get used to the crontab format soon enough). Now, there are a few advanced tricks that work with this syntax as well:

• 8-16 (hyphens allows multiple values, so 00 8-16 * * * would mean every full hour from 08:00 to 16:00).
• */5 allows every 5 units (most often used in the first location, for every 5 minutes). The value */6 for hours is useful as well, for four times a day.
• 00,30 for two values, such as every 30 minutes on the hour or half hour (which could also be written as */30).

Before we get too bogged down in the theory, let's create a simple first crontab for our user using the crontab command. The crontab command has three interesting flags you'll use most often:-l for list, -e for edit, and -r for remove. Let's create (and remove) our very first crontab using these three commands:

reader@ubuntu:~$ crontab -l
no crontab for reader
reader@ubuntu:~$ crontab -e
no crontab for reader - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]: 2
crontab: installing new crontab
reader@ubuntu:~$ crontab -l
# m h  dom mon dow   command
* * * * * wall "Crontab rules!"

Broadcast message from reader@ubuntu (somewhere) (Sun Nov 25 16:25:01 2018):

Crontab rules!

reader@ubuntu:~$ crontab -r
reader@ubuntu:~$ crontab -l
no crontab for reader

As you can see, we start by listing the current crontab using the crontab -l command. Since we do not have one, we see the message no crontab for reader (no surprises there). Next, when we use crontab -e to start editing the crontab, we'll get a choice: which editor do we want to use? As always, do whatever works best for you. We have enough experience with vim to prefer it over nano. We only have to do that once for each user, because Linux will save our preference (check out the ~/.selected_editor file). Then, finally, we're presented with a text editor screen, which, on our Ubuntu machine, is filled with a little tutorial on crontabs. Since all these lines start with a #, all are considered comments and do not interfere with execution. Usually, we delete everything except the syntax hint: m h dom mon dow command. You can expect to forget this syntax a few times, which is why that little hint helps a lot when you need to do a quick edit, especially if it has been a while since you've interacted with a crontab.

We create a crontab with the simplest time syntax of all: wildcards in all five positions. Simply said, that means the command specified after is run every minute. After we save and exit, we wait a maximum of one minute before we see the result of the wall "Crontab rules!"; command a broadcast from our own user, visible to all users on the system. Because this construction spams up the system pretty badly, we remove the crontab after a single broadcast by using crontab -r. Alternatively, we could have also removed just that line or commented it out.

As stated, all crontabs are saved as files in the filesystem. You can find them in the /var/spool/cron/crontabs/ directory. This directory is accessible to the root user only; it would have some big privacy concerns if all users could see each other's job schedules. If you use sudo to become root, however, you would see the following:

reader@ubuntu:~$ sudo -i
[sudo] password for reader: 
root@ubuntu:~# cd /var/spool/cron/crontabs/
root@ubuntu:/var/spool/cron/crontabs# ls -l
total 4
-rw------- 1 reader crontab 1090 Nov 25 16:51 reader

If we were to open this file (vim, less, cat, whatever you prefer), we'd see the same as a crontab -e for the reader user would show us. As a general rule, though, always use the available tools to edit files like these! The primary added benefit of this is that these tools do not allow you to save an incorrect format. If we were to edit the crontab file by hand and get the time syntax wrong, the entire crontab will no longer work. If you do the same with crontab -e, you will see an error and the crontab will not be saved, as follows:

reader@ubuntu:~$ crontab -e
crontab: installing new crontab
"/tmp/crontab.ABXIt7/crontab":23: bad day-of-week
errors in crontab file, can't install.
Do you want to retry the same edit? (y/n)

In the preceding example, we entered the line * * * * true. As can be seen from the error, where cron expects a digit or wildcard, it finds the command true (which, as you might recall, is a command which simply returns an exit code of 0). It presents the user with an error, and refuses to save the new edit, which means all previous scheduled jobs are safe and will continue to run, even though we messed it up this time.