Most of the time the cron job does run, and fails for one of six reasons: an incomplete path, an unprotected % sign, the wrong PHP version, a script without permission, the server’s clock, or output thrown away. Go down the list in order; the first one you find is usually the cause. If you have not created the job yet, start with cron jobs: what they are for and how to create one.
First, find out whether it runs
| 1 |
Add a log. At the end of the command put >> /home/ACCOUNT/cron.log 2>&1. You now keep everything the command prints, errors included.
|
|
| 2 |
Put your e-mail in the notification field on the cron page, and leave out >/dev/null while you test. If the message arrives, the job started.
|
|
| 3 |
Schedule it for a few minutes from now. In server time, which may not be yours: type date in the cPanel Terminal (if your account has one) to see it. Put the normal schedule back once it works.
|
|
| 4 |
Run the same command by hand in the Terminal, copied from the cron line. If it fails there, the error shows on screen and the cause is in the command, not in cron.
|
|
The causes, most common first
| Symptom |
Likely cause |
What to do |
| Works in the Terminal, not in cron |
Cron does not start in your site folder and has very few environment variables. |
Use full paths for everything, from /home/ACCOUNT/. In PHP, use __DIR__ in your require lines. |
A job with date +%F or %Y fails |
In cron, the % sign means end of line. |
Write \%. Example: date +\%F. |
| Extension or version errors |
The job uses a different PHP version from the site. |
Call the PHP version the site uses, or check the extension in Select PHP Version. |
“Permission denied” on a .sh script |
The file is not executable. |
Run it with /bin/bash /home/ACCOUNT/scripts/x.sh, or give it execute permission. |
“bad interpreter” or odd errors in the .sh |
The file was saved with Windows line endings. |
Save it again with Unix (LF) line endings in your editor. |
| Runs at a time you did not expect |
The server has its own clock, which may not be yours. |
Adjust the schedule to server time. See the server time. |
| You get no e-mail at all |
Output goes to /dev/null, or the notification field is empty. |
Remove the >/dev/null until you trust the job. |
|
A silent job that never worked looks exactly like one that does. Always make the script leave proof, such as a line with the date in a file or a table. It is the only way to know it not only started but reached the end.
|
If the script needs a lot of memory or time, it may be cut off by the account limits and leave only a line in the PHP error log. See where the PHP error log is. If the account’s disk is full, the script cannot write anything either.
|
Before you schedule it, run the command once by hand and confirm it does what you want. Only then put it in cron. A new job that fails the first time usually fails over a detail of the command rather than because of cron.
|
|
Still not running? Send us the full line and the domain, and we will tell you what cron did. Bear in mind that what is inside the script is yours.
Open a ticket
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $6.60/mo (3-year plan, with coupon) See plans |
Angola
Brasil
Kenya
Moçambique
Nigeria
Portugal
South Africa
United Kingdom
United States
International
