The usual problem with 'cron' jobs is that they have zero environment - unlike 'at' jobs which do copy your environment. When something works from the command line and not from 'cron', my experience is that 'environment' is one of the most common problems. Occasionally you run into another problem - 'cron' jobs are not run with a terminal, and occasionally programs get stroppy about this. However, this is in the 1% range compared with 99% for environment issues.
The other key technique I use is to always run a shell script from 'cron'; the shell script ensures that the environment is set correctly and then runs the real program. If a 'cron' job is giving me problems, I can then tweak the script to do useful things like this:
{
date
env | sort
set -x
...what was there before adding the debug...
} >/tmp/cron.jobname.$$ 2>&1
This redirects all the output - standard output and standard error - to a file name. You can build timestamps into the filename if you prefer that to the process ID. Analyzing the log files often reveals the problems swiftly.
To edit/view your crontab, type the following commands:
crontab -e # to edit
crontab -l # to view
Your cron job looks like as follows:
1 2 3 4 5 /path/to/command
Where 1 = minutes (0-59), 2 = hours (0-23), 3 = day (0-31), 4 = month (1-12), 5 = day of week (0-7).
For example, if I want to run something 5min after midnight, every day:
5 0 * * * /path/to/command
You can also specify multiple values, separated by commas or hyphens, such as:
5,10 0-2 * * * /path/to/command
which runs at 00:05, 00:10, 01:05, 01:10, 02:05 and 02:10 each day.
Best Answer
This will run the job every night at midnight.
Here's what that job would look like in cpanel: