Linux concept: cron

Almost every server runs work that nobody watches. A backup at three in the morning, a certificate renewal twice a month, a cache that gets cleared every hour. The program that makes that happen has been doing the same job since 1979, in almost the same way, and it is called cron. It is also one of the easiest tools on a Linux system to get subtly wrong, because a broken cron job and a working cron job look exactly the same: silent.

2. Where the Name Comes From

The name is generally taken to come from the Greek chronos, time. The author of the original program never wrote the derivation down, so treat that as the accepted explanation rather than a documented fact. What the surrounding names mean is not in doubt:

cron       the daemon that watches the clock
crontab    cron TABle - both the file and the command that edits it
cron.d     a drop-in directory of cron fragments
anacron    "anachronistic" cron: for machines that are not always on

The trailing d in crond on Red Hat systems is the usual Unix suffix for a daemon, the same one you see in sshd, httpd and systemd. Debian and Ubuntu simply left it off.

One naming detail matters in practice. Because both the file and the command are called crontab, the manual has two different pages for them, in two different sections:

$ man 1 crontab      # the command: -l, -e, -r
$ man 5 crontab      # the file format: the five fields

Almost everything people search the web for is in crontab(5), and almost nobody opens it.

4. Simple Use Cases

4.1 The Five Fields

A line in a user crontab is five time fields and then everything else, which is the command. The comment block that Debian ships in /etc/crontab is the best diagram of it, and it is already on your machine:

# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,...
# |  |  |  |  |
# *  *  *  *  *  command to be executed

Read a line right to left and it says itself out loud. This one runs at 03:30 every day:

30 3 * * * /usr/local/bin/backup.sh

An asterisk means "every value of this field". So the line above is: minute 30, hour 3, every day of the month, every month, every day of the week.

Both 0 and 7 mean Sunday in the day-of-week field, which is a historical compromise between two Unix families that disagreed. You can also write three-letter names, in either case:

0 4 * * 1        # Monday at 04:00
0 4 * * mon      # exactly the same
0 4 * * MON      # also the same, case does not matter

Names are not allowed in ranges or lists, so mon-fri works but a mixed list of names and numbers does not. When in doubt, use numbers.

4.2 Editing Your Own Crontab

Three commands cover almost everything:

Look at -e and -r on a keyboard. They are next to each other, they do very different things, and there is no undo. This is a genuinely famous way to lose an afternoon. Two habits protect you:

$ crontab -l > ~/crontab.backup     # before you touch anything
$ crontab -i -r                     # -i asks for confirmation first

The last row of the table is worth knowing for another reason: crontab file means your jobs can live in version control. Keep the real file in a repository, and install it with one command:

$ crontab -n deploy.cron       # dry run: check the syntax, install nothing
$ crontab deploy.cron          # replace the live crontab with this file

The -n flag (short for no action) is not widely known and is exactly what you want in a deployment script: it parses the file, reports any error, and exits without changing anything.

4.3 Where the Output Goes

This is the single most important thing to understand about cron, and it has nothing to do with the schedule.

Anything a cron job prints is treated as an error report. If a job writes to standard output or standard error, cron mails that text to the owner of the crontab. If the job prints nothing, cron says nothing.

On a desktop or a modern server there is usually no mail system installed, so that mail goes nowhere at all. Your job runs, prints an error, and the error is discarded. This is why broken cron jobs are silent.

The fix is to decide where the output goes yourself:

30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Read the tail of that line carefully, because the order matters:

Writing 2>&1 >> file instead is a classic mistake: it points error output at the terminal cron gave you (which is nothing), and only then redirects standard output. The redirection has to come first.

You will also see > /dev/null 2>&1 on a lot of lines found on the internet. That silences the job completely. It is the right choice for a job that does its own logging, and the wrong choice for everything else, because it throws away the only warning you were going to get.

4.4 The Shorthands

Vixie cron added eight special strings that replace all five fields:

They read well, but there is a catch worth knowing before you use them on a busy server: every @daily job on the machine fires at exactly 00:00, and every @hourly job at exactly minute 0. Spreading load is a good reason to write the fields out and pick an odd minute.

@reboot has a warning in its own manual page. It runs when the cron daemon starts, which during boot may be before the network, the database, or the filesystem your job needs. For anything with real dependencies, a systemd unit is the correct tool, and section 6.10 shows why.

6. Advanced Use Cases

6.1 The Environment a Cron Job Really Gets

"It works when I run it by hand but not from cron" is the most common cron complaint there is, and the environment is almost always the reason. Rather than repeat the folklore, here is a measurement. This crontab ran on the machine this article was written on:

$ crontab -l
* * * * * /usr/bin/env > /tmp/cron-env.txt 2>&1

$ cat /tmp/cron-env.txt
HOME=/home/peter
LOGNAME=peter
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
LANG=en_US.UTF-8
SHELL=/bin/sh
PWD=/home/peter

Six variables. That is the entire world your job runs in. Three details in that list matter more than the rest.

The PATH advice you have read is probably out of date. Every cron tutorial says cron gives you a crippled PATH of /usr/bin:/bin. That is not what happened here, and the reason is visible in the service definition:

$ systemctl cat cron.service | grep ExecStart
ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS

The -P flag means "do not set PATH for child processes, let it inherit instead". So on this system the value comes from /etc/environment by way of PAM, and it is a perfectly normal system PATH.

The useful lesson survives the correction, and it is sharper than the folklore: cron gives you a system PATH, never your PATH. Compare the two on the same machine:

$ echo $PATH        # interactive shell
/bin:/home/peter/.local/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:...
                    # plus a version manager, plus node_modules/.bin, plus more

Everything your .bashrc or .profile added is gone: ~/.local/bin, anything installed by nvm, rbenv or pyenv, and any per-project directory. A job that calls node or composer by bare name works in your terminal and fails under cron for exactly this reason.

SHELL is /bin/sh, not bash. On Debian and Ubuntu /bin/sh is dash, which is a smaller, faster, stricter shell. Anything bash-specific fails: [[ ... ]], arrays, source instead of ., ${var,,}. The failure is often a single confusing line in a log you are not reading.

What is missing matters too. There is no SSH_AUTH_SOCK, so a job that pushes to git over SSH cannot use your agent. There is no XDG_RUNTIME_DIR, so systemctl --user and rootless container tools misbehave. There is no DISPLAY, so nothing graphical works.

There are three ways to deal with this, in increasing order of robustness:

# 1. Set what you need at the top of the crontab
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:/home/peter/.local/bin

# 2. Use absolute paths everywhere, always
30 3 * * * /usr/bin/php /var/www/site/cli/joomla.php scheduler:run --all

# 3. Best: call a script, and let the script set up its own world
30 3 * * * /usr/local/bin/nightly.sh

The third option is the one to reach for. A one-line crontab entry that calls a script keeps the schedule and the work separate, puts the logic in version control, and lets you run the exact same thing by hand while you are testing.

6.2 The Working Directory Is Not Where Your Script Lives

The measurement above contains one line that causes more failures than it looks like it should:

PWD=/home/peter

cron starts your job in the home directory of the user it runs as. Not in the directory the script lives in, and not in the directory you happened to be standing in when you wrote the crontab entry. For jobs in /etc/cron.d it is the home directory of the user named in the sixth field, which for www-data on Debian is /var/www. For the run-parts directories it is /, because /etc/crontab says cd / && before every one of them.

Any script that reaches for a file relative to itself breaks:

require 'config.php';          # PHP, resolved against the working directory
. ./settings.sh                # shell
source venv/bin/activate       # python virtualenv
cat ../data/input.csv          # anything at all

All four work when you run the script from its own folder and fail from cron, with an error that goes to a mail nobody reads. There are two good fixes and one bad one:

# Acceptable: change directory in the crontab entry
0 3 * * * cd /var/www/site && /usr/bin/php cli/import.php

# Better: let the script find itself, so it works from anywhere
#!/bin/bash
cd "$(dirname "$0")" || exit 1

# Best: never use relative paths inside a scheduled script at all

The middle one is worth adopting as a habit. Two lines at the top of every script you schedule removes the entire class of problem, and it also means you can run the script by hand from your own home directory while testing.

6.3 Debugging a Job That Does Not Run

"My cron job does not work" is really six different questions, and answering them in order finds the problem far faster than guessing. Work down this list and stop at the first step that fails.

1. Is cron running your crontab at all? Before anything else, prove the plumbing works. Install a job that cannot fail:

* * * * * /usr/bin/date >> /tmp/cron-test.log 2>&1

Wait a minute. If /tmp/cron-test.log does not appear, the problem is not your script: it is the daemon, the crontab, or permission to use cron at all. Check systemctl is-active cron and section 6.6.

2. Did cron try? The log tells you what cron started, and it prints the command exactly as cron parsed it. This is where a percent sign shows up as a truncated command:

$ journalctl -t CRON --since '-10 min'

3. Does the command work by hand? Run the exact text from the crontab in your own shell. If it fails here, cron was never the problem.

4. Does it work as the right user? A job under www-data has different permissions, a different home directory, and possibly no shell. Test as that user:

$ sudo -u www-data /usr/bin/php /var/www/site/cli/joomla.php scheduler:run --all

This one step finds most permission problems immediately, and it is the step people skip.

5. Does it work in cron's environment? This is where the PATH and shell differences from 6.1 surface. Strip your environment down and try again:

$ env -i /bin/sh -c '/usr/local/bin/job.sh'

For the exact truth rather than an approximation, schedule /usr/bin/env for one minute and read what comes back, as in 6.1.

6. Is the output being thrown away? If the job runs and nothing happens, add a redirect and look at what it says. A wrapper that records the surroundings alongside the output turns an invisible failure into an obvious one:

#!/bin/bash
LOG=/var/log/myjob.log
{
    echo "===== $(date --iso-8601=seconds) ====="
    echo "user: $(id -un)  pwd: $(pwd)"
    echo "PATH=$PATH"
    /usr/bin/php /var/www/site/cli/import.php
    echo "exit: $?"
} >> "$LOG" 2>&1

One more check applies only to the cron.daily family: if the script is in one of those directories, run run-parts --test on it before anything else. A filename problem makes every step above look fine while nothing ever executes. Section 7.3 has the details.

6.4 Stopping Jobs From Overlapping

cron will happily start a job while the previous run is still going. A backup that normally takes four minutes and is scheduled every five minutes will, on a bad day, run twice at once. Two copies writing the same file is how backups get corrupted.

cron has no option for this, but flock solves it in one word:

*/5 * * * * flock -n /tmp/backup.lock /usr/local/bin/backup.sh

The -n flag (short for nonblock) means: if the lock is already held, give up immediately rather than waiting. The second run exits silently and the first keeps going. Two variations are worth knowing:

Put the lock file somewhere that survives, such as /var/lock, if the job matters. Locking is one line, and it prevents a class of failure that is genuinely difficult to debug afterwards.

Overlap is not the only way a scheduled job hurts the machine it runs on. A nightly report that pins every core, or a backup that saturates the disk, will slow down the website that is the reason the server exists. Two wrappers cost nothing:

0 2 * * * nice -n 10 ionice -c 3 /usr/local/bin/report-generator

nice -n 10 lowers the CPU priority, so anything interactive wins. ionice -c 3 puts the job in the idle I/O class, where it only gets disk access when nothing else wants it. Neither makes the job slower on an idle machine; both make it invisible on a busy one.

6.5 anacron, for Machines That Are Not Always On

cron has no memory. A laptop that is closed at 06:25 never runs the daily jobs, and it never catches up. anacron exists for exactly this, and its own manual page states the difference plainly: it does not assume the machine is running continuously, and it measures periods in days rather than clock times.

Its table has four columns instead of five fields:

$ cat /etc/anacrontab
SHELL=/bin/sh
HOME=/root
LOGNAME=root

# period(days)  delay(min)  job-identifier   command
1               5           cron.daily       run-parts --report /etc/cron.daily
7               10          cron.weekly      run-parts --report /etc/cron.weekly
@monthly        15          cron.monthly     run-parts --report /etc/cron.monthly

Read the first line as: "run this at most once a day; when you do start it, wait five minutes first". anacron records a timestamp per job identifier after each successful run, and on the next start it compares the date. If the last run was yesterday or earlier, the job is due. The delay staggers jobs so that a machine waking up does not run everything at once.

Only the date is compared, never the hour. anacron is the right tool for "roughly daily" work and the wrong tool for anything that must happen at a specific time.

This also explains those test -x /usr/sbin/anacron || guards in /etc/crontab. If anacron is installed, cron steps back from the daily, weekly and monthly directories and lets anacron own them, so the two never both run the same script.

6.6 Who Is Allowed to Use cron

Two files control access, and the logic has one surprise:

root can always install a crontab regardless of either file. On a shared or hosting server, an empty /etc/cron.allow listing only the accounts that need it is a cheap and effective restriction, because it denies everyone else by default rather than requiring you to name them.

One permission detail bites people: both files must be world-readable, or readable by the crontab group. If they are not, cron denies access to every user until the permissions are fixed.

6.7 Keeping a Scheduled Job Secure

A cron job is an unattended command that runs as somebody, often as root, forever. That deserves the same care as any other privileged automation, and two specific mistakes come up again and again.

A command line is public. Anything you put in a crontab is visible in the process list while it runs, to every user on the machine:

$ ps -eo user,args | grep curl
root  curl -u admin:supersecret https://api.example.com/backup

Unless the system is configured with hidepid, which is not the default, any local account can watch for that. The same secret also ends up in the crontab file, in your backups of that file, and in any log that records the command. Keep credentials in a file the job reads instead:

$ sudo install -o root -g root -m 600 /dev/null /etc/myapp/backup.env
$ sudoedit /etc/myapp/backup.env          # API_TOKEN=...

# and in the script, not in the crontab:
. /etc/myapp/backup.env
curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com/backup

A root job is only as safe as the file it runs. This line looks fine:

0 3 * * * root /usr/local/sbin/backup.sh

If any unprivileged user can write to backup.sh, that user can put anything they like in it and root will run it at three in the morning. That is not a backup script any more, it is a root shell on a timer. The same applies to the directory containing it, because being able to replace a file is as good as being able to edit it.

$ ls -ld /usr/local/sbin /usr/local/sbin/backup.sh
drwxr-xr-x 2 root root 4096 Aug 23 12:00 /usr/local/sbin
-rwxr-xr-x 1 root root  842 Aug 23 12:00 /usr/local/sbin/backup.sh

Both should be owned by root and writable by nobody else. cron already enforces this for the crontab files themselves, which is why /etc/cron.d entries are ignored unless they are root-owned and not group- or world-writable, but nothing checks the script at the other end of the line. That check is yours.

The third rule needs no example: do not run a job as root because it is easier. Most scheduled work needs one directory and one database, so give it an account with exactly that.

6.8 Driving a Web Application's Scheduler

Most modern web applications have their own task scheduler and expect a single cron entry to drive it. Joomla is a good example, because it ships a console application for exactly this. The command names come straight from the installed source:

$ php /var/www/site/cli/joomla.php scheduler:list
$ php /var/www/site/cli/joomla.php scheduler:run --all
$ php /var/www/site/cli/joomla.php scheduler:run --id 3

The crontab entry that drives it needs three things that are easy to get wrong:

*/5 * * * * www-data /usr/bin/php /var/www/site/cli/joomla.php scheduler:run --all >> /var/log/joomla-cron.log 2>&1

• Run as the web server user. If you run it as root, every cache file and log the application writes ends up owned by root, and the website itself can no longer write to them. This is a very common way to break a site with a cron job that "works".
• Use the absolute path to PHP. There is often more than one PHP on a server, and the CLI version is not always the one the web server uses. which php in your shell may not be what cron finds.
• Log the output. The scheduler reports what it ran. Without a redirect that report is mailed into a void.

The same pattern applies to any application with a scheduler: run it as the application's user, with an absolute interpreter path, and send the output to a file. The application decides which tasks are due; cron only supplies a heartbeat.

The second point deserves more than one line, because "PHP is PHP" is not true. The PHP that cron runs is the CLI build, and on Debian and Ubuntu it has its own configuration, entirely separate from the one your website uses:

$ php --ini
Configuration File (php.ini) Path: /etc/php/8.3/cli
Loaded Configuration File:         /etc/php/8.3/cli/php.ini
Scan for additional .ini files in: /etc/php/8.3/cli/conf.d

Read the path. That cli component is a directory name, and there is a sibling fpm directory next to it holding a different php.ini and a different set of enabled extensions. Four things follow, and each one has caused a support ticket:

• Different limits. CLI usually ships memory_limit = -1 and no execution time limit, while FPM has real ones. A task that dies in the browser may run happily from cron, and a task tested from cron may die in the browser.
• Different extensions. An extension enabled for FPM is not automatically enabled for CLI. The job fails with "class not found" for something the website clearly has.
• Different versions. On a server with several PHP versions installed, /usr/bin/php is whichever one is the default alternative, and the site may be running a different one under FPM.
• Different everything, in a container. If the site runs in Docker, the host's /usr/bin/php is not the site's PHP at all, and the cron entry has to go through the container.

Three commands settle it before you schedule anything:

$ /usr/bin/php -v         # which version cron will actually use
$ /usr/bin/php --ini      # which configuration it loads
$ /usr/bin/php -m         # which extensions are enabled for CLI

On a server with more than one version, name the version explicitly in the crontab (/usr/bin/php8.3) rather than trusting the default to stay where it is through the next upgrade.

6.9 Knowing That It Actually Worked

cron starts a command and forgets it. It never looks at the exit code, so from cron's point of view a backup that wrote nothing and a backup that wrote fifty gigabytes are identical events. If you want to know which one happened, the job has to say so.

Start by making the script honest. A shell script returns the status of its last command, which is rarely what you mean:

#!/bin/bash
set -euo pipefail     # stop on the first error, and on a failure inside a pipe

Without pipefail, mysqldump ... | gzip > out.gz reports success whenever gzip succeeds, which it does even when it is handed nothing at all.

Then leave a mark that something outside can check. The pattern is one line, and the && is the whole trick:

30 3 * * * /usr/local/bin/backup && touch /var/lib/myapp/backup.last-success

The timestamp only moves when the job succeeded. Now "did the backup run last night?" becomes a question anyone can answer, including a monitoring system that has no idea what a backup is:

$ find /var/lib/myapp/backup.last-success -mmin +1500
/var/lib/myapp/backup.last-success        # printed = older than 25 hours = alert

This is stronger than checking whether cron is running, and much stronger than checking whether the job appears in the log, because it reports on the work rather than on the attempt. Useful signals, roughly in order of how much they tell you:

For anything that matters, push rather than pull: have the job call a monitoring endpoint on success, and let that service raise the alarm when the call does not arrive. A job that fails silently and a job that was deleted six weeks ago look the same from the server. They do not look the same to something waiting for a heartbeat.

6.10 systemd Timers, the Modern Alternative

On any systemd machine there is a second scheduler already running, and a surprising amount of the work you assume cron does has quietly moved to it:

$ systemctl list-timers --all
NEXT                          LEFT       LAST                          UNIT
Sun 2026-08-23 15:39:00 CEST  4min 38s   Sun 2026-08-23 15:09:04 CEST  phpsessionclean.timer
Sun 2026-08-23 16:34:21 CEST  59min      Sun 2026-08-23 15:31:08 CEST  anacron.timer
Mon 2026-08-24 00:00:00 CEST  8h         Sun 2026-08-23 00:00:05 CEST  logrotate.timer
Mon 2026-08-24 01:47:50 CEST  10h        Sun 2026-08-23 05:28:44 CEST  man-db.timer

A timer is two files: a .timer that says when, and a .service that says what. Here is the one that replaced the PHP session cleanup from section 5.2, which is why that cron entry has a systemd test around it:

$ systemctl cat phpsessionclean.timer
[Unit]
Description=Clean PHP session files every 30 mins

[Timer]
OnCalendar=*-*-* *:09,39:00
Persistent=true

[Install]
WantedBy=timers.target

That OnCalendar line is the direct equivalent of 09,39 * * * *. The syntax reads year-month-day hour:minute:second, and it supports the same lists and steps that cron does. Unlike cron, you can ask whether you got it right before trusting it:

$ systemd-analyze calendar "*-*-* *:09,39:00"
Normalized form: *-*-* *:09,39:00
    Next elapse: Sun 2026-08-23 15:39:00 CEST
       (in UTC): Sun 2026-08-23 13:39:00 UTC
       From now: 2min 15s left

There is no cron command that does this, and it alone is a reason to reach for a timer when the schedule is complicated.

The honest summary: for "run this script every night", cron is one line and there is no reason to change. For anything that must survive downtime, wait for another service, be resource-limited, or be tested before it goes live, a timer is the better tool and its logging alone repays the extra file.

8. Best Practices

• Put the work in a script, not in the crontab. One line that calls /usr/local/bin/nightly.sh keeps the schedule separate from the logic, puts the logic in version control, lets you test by running it yourself, and means you never have to escape a percent sign.
• Always redirect the output. End every line with >> /var/log/thing.log 2>&1, in that order. Without it, the only report of a failure is a mail that probably goes nowhere.
• Use absolute paths for everything. Both the interpreter and the script. cron's PATH is a system PATH, not yours, and nothing your shell profile added is present.
• Test the command in cron's environment, not yours. env -i /bin/sh -c '/usr/local/bin/job.sh' gets you close, and a temporary * * * * * entry running env gets you the exact truth.
• Back up before you edit. crontab -l > ~/crontab.backup takes a second, and -r sits next to -e on the keyboard with no confirmation and no undo.
• Check the syntax before you install. crontab -n file parses without changing anything, which is what you want inside a deployment script.
• Never restrict both day fields on the same line. They are combined with OR, not AND. Leave one as * and put the extra condition in the command.
• Make every scheduled script find its own directory. cron starts you in the user's home directory, not next to the script. cd "$(dirname "$0")" at the top removes a whole class of "works by hand, fails from cron".
• Keep secrets out of the crontab. A command line is visible to every user on the machine through ps. Put credentials in a file mode 0600 and read it from the script.
• Check who can write the script a root job runs. If an unprivileged user can edit it, or edit the directory holding it, they own root. cron checks the crontab file's permissions and nothing else.
• Rotate whatever you log to. A file appended to every five minutes fills a disk eventually. A stanza in /etc/logrotate.d, or a pipe into logger, takes one minute.
• Leave a success marker, and alert on its age. job && touch /var/lib/app/last-success turns "did it work?" into a question a monitoring system can answer without knowing anything about the job.
• Be a good neighbour on a busy machine. nice -n 10 ionice -c 3 in front of a heavy job keeps it from competing with the website the server exists for.
• Add flock -n to anything that might run long. One word prevents two copies of a backup writing the same file.
• Prefer /etc/cron.d for server jobs. Ordinary files that configuration management can deploy, with an explicit user field, and no dot in the filename.
• Run application jobs as the application's user. A scheduler run as root leaves root-owned cache files behind and breaks the site it was meant to maintain.
• Monitor from outside. Have the job report success to a monitoring service when it finishes. cron's silence is identical whether the job worked, failed, or has not run since March.

$ man 5 crontab           # the file format: fields, steps, the OR rule, the % rule
$ man 1 crontab           # the command: -l, -e, -r, -n, -i
$ man 8 cron              # the daemon: logging, DST, Debian specifics
$ man 8 anacron           # for machines that are not always on
$ man 8 run-parts         # the filename rules for cron.daily and friends
$ man 7 systemd.time      # OnCalendar syntax, if you move to timers

10. Summary

cron is a small, old, extremely reliable program that does exactly one thing, and most of the trouble people have with it comes from expecting it to do more.

• cron wakes once a minute, compares the clock to a list of rules, and runs whatever matches. It has no queue, no memory, and no interest in whether a job succeeded.
• Jobs live in three kinds of place: user crontabs (five fields), /etc/crontab and /etc/cron.d (five fields plus a user), and the cron.daily style directories (scripts, no schedule).
• The five fields are minute, hour, day of month, month, day of week. Both 0 and 7 mean Sunday.
• Ranges, lists and steps combine freely, but a step restarts at the top of its field, so */7 is not an even interval.
• If both day fields are restricted, they are combined with OR. Never restrict both.
• An unescaped % ends the command and becomes standard input. Escape it as \%, or put the command in a script.
• Output is mailed, and on most servers that mail goes nowhere. Redirect with >> file 2>&1 or you will never learn that a job failed.
• The environment is six variables. The PATH is a system PATH, not yours, and the shell is /bin/sh, not bash.
• In cron.daily and cron.d, a filename containing a dot is silently ignored. Check with run-parts --test.
• Jobs start in the user's home directory, not next to the script, so relative paths fail.
• cron never looks at the exit code. If you want to know that a job worked, leave a success marker and alert on its age.
• A crontab command line is visible to every user through ps, and a root job that runs a user-writable script is a root shell on a timer.
• cron uses one timezone for everyone, and handles daylight saving sensibly for fixed-time jobs.
• flock -n stops runs from overlapping. anacron covers machines that are switched off.
• systemd timers do catch-up, dependencies, randomised delays, resource limits and journal logging. For anything beyond "run this nightly", they are the better tool.

This is the quick reference worth keeping:

# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) or jan,feb,...
# |  |  |  |  .---- day of week (0 - 7) (0 and 7 are Sunday) or sun,mon,...
# *  *  *  *  *  command

crontab -l                     list your jobs
crontab -e                     edit them
crontab -l > backup.txt        back them up FIRST
crontab -n file                check syntax, install nothing
crontab file                   install from a file (version control)
crontab -i -r                  delete, with a confirmation prompt
crontab -u www-data -l         another user's jobs (root only)

*/5 * * * *                    every 5 minutes
15 */6 * * *                   00:15, 06:15, 12:15, 18:15
30 3 * * *                     03:30 every day
0 4 * * 1                      Mondays at 04:00
0 2 1 * *                      1st of the month at 02:00
@reboot                        when the cron daemon starts
@daily @weekly @monthly        midnight shorthands (all at 00:00)

... >> /var/log/job.log 2>&1   keep the output (order matters)
... > /dev/null 2>&1           throw it away on purpose
MAILTO=""                      no mail for any job in this file
flock -n /var/lock/j.lock ...  do not overlap with the previous run
nice -n 10 ionice -c 3 ...     stay out of the way on a busy machine
... 2>&1 | logger -t myjob     log to syslog instead of a file you must rotate
job && touch /var/lib/ok       success marker, for monitoring to check the age of
\%                             a literal percent sign

journalctl -t CRON             what cron started
run-parts --test /etc/cron.d   what would run from a directory
sudo -u www-data CMD           test as the user the job will run as
env -i /bin/sh -c 'CMD'        test in something close to cron's environment
php --ini                      which php.ini the CLI build loads
ps -eo user,args               proof that command lines are not private
systemctl edit cron.service    add -L 15 to log endings and failures
systemd-analyze calendar "..." test a systemd timer schedule

A scheduled job is one of the few parts of a server that nobody looks at until the day it matters. If you want the backups, renewals and cleanups on your server set up so that they are visible when they work and noisy when they fail, rather than silent either way, that is exactly the kind of quiet work I enjoy helping with.