![cPanel Cron Jobs for Beginners: 7 Errors [Solved]](/images/blog/cpanel-cron-jobs-for-beginners-7-errors-solved.jpg)
You set up a cron job in cPanel to back up your database every night. Morning comes, no backup file. The cron ran—cPanel sent you an email—but it did nothing. I've walked hundreds of users through this exact scenario, and the culprit is almost always one of seven fixable mistakes.
This guide walks you through each error with the symptom you'll see, the root cause, and the exact fix. No theory, just the troubleshooting steps that actually resolve tickets.
Error 1: Permission Denied on Script
What you see
You get a cron email that says:
/bin/sh: /home/username/backup.sh: Permission denied
The job ran. The shell tried to execute your script. It couldn't.
Root cause
Your script file isn't executable. When you upload a .sh or .php file via FTP or cPanel File Manager, it lands with 644 permissions by default—readable and writable, but not executable. The cron daemon can't run it.
The fix
SSH into your account or use the Terminal in cPanel and run:
chmod +x /home/username/backup.sh
If you don't have SSH access, open File Manager in cPanel, right-click the script, choose Permissions, and check the Execute boxes for User.
Run the cron manually from the shell to confirm:
/home/username/backup.sh
If it executes without error, the next cron run will work. Permission issues are the single most common reason cron jobs silently fail on shared hosting.
Error 2: Command Not Found
What you see
The cron email contains:
/home/username/scripts/backup.sh: line 5: mysqldump: command not found
Your script ran. A command inside it didn't exist.
Root cause
cPanel cron jobs run with a minimal PATH environment variable—usually just /usr/bin:/bin. If your script calls mysqldump, php, wp, or any binary that lives in /usr/local/bin or another directory, the shell won't find it. When you run the same script from an SSH session, your interactive shell has a full PATH and everything works.
The fix
Use absolute paths for every command in your script. Find the real location:
which mysqldump
You'll get something like /usr/bin/mysqldump. Edit your script to use that full path:
#!/bin/bash
/usr/bin/mysqldump -u dbuser -p'password' dbname > /home/username/backups/db.sql
Do the same for php, gzip, tar, or anything else your script calls. Alternatively, set PATH at the top of the script:
#!/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
export PATH
mysqldump -u dbuser -p'password' dbname > /home/username/backups/db.sql
I prefer absolute paths because they're explicit and survive environment changes.
Error 3: No Output, No Email
What you see
Nothing. The cron should send you an email every time it runs—that's the default—but your inbox is empty. You're not sure if the job even fired.
Root cause
cPanel cron jobs send email only when the command produces output to stdout or stderr. If your script runs silently (exits with status zero and prints nothing), no email is sent. You assume failure when in fact the job succeeded.
The fix
Add explicit output to your script so you know it ran. A single echo line is enough:
#!/bin/bash
echo "Backup started at $(date)"
/usr/bin/mysqldump -u dbuser -p'password' dbname > /home/username/backups/db.sql
echo "Backup completed"
Now every run sends an email with those timestamps. If the job breaks later, you'll see where it stopped.
If you want zero email (because the script runs every minute and you don't need inbox spam), redirect both stdout and stderr to /dev/null in the cron command itself:
* * * * * /home/username/script.sh > /dev/null 2>&1
But during troubleshooting, leave output enabled so you can see what's happening.
Error 4: Wrong PHP Binary or Version
What you see
You run a PHP script via cron:
* * * * * php /home/username/public_html/task.php
The email says:
Parse error: syntax error, unexpected '?' in /home/username/public_html/task.php on line 8
Your script works fine when you visit it in a browser or run it from SSH with php task.php.
Root cause
The php binary in cron's PATH is a different version than the one your website uses. Shared hosting often has multiple PHP versions installed (/usr/bin/php might be 5.6 while your site runs 8.1). The old binary can't parse modern syntax like nullable types or match expressions.
The fix
Find the correct PHP binary for your account. In cPanel, go to Select PHP Version (under Software or MultiPHP Manager). Note the version your site uses. Then SSH in and check:
which php
/opt/cpanel/ea-php81/root/usr/bin/php --version
Use the full path in your cron command:
* * * * * /opt/cpanel/ea-php81/root/usr/bin/php /home/username/public_html/task.php
The exact path varies by host and PHP version. Many hosts symlink the current version to /usr/local/bin/php or expose an ea-php81 wrapper. Check your hosting documentation or run ls -l /opt/cpanel/ to see what's available.
So what if the script path is wrong?
Error 5: Relative Path Issues
What you see
Your cron runs a PHP script that includes other files:
require_once 'config.php';
The cron email says:
Warning: require_once(config.php): failed to open stream: No such file or directory
But the file exists in the same directory as your script.
Root cause
cron jobs execute with the working directory set to your home directory (/home/username), not the directory where your script lives. When your PHP script uses a relative path like config.php, PHP looks in /home/username/config.php instead of /home/username/public_html/config.php.
The fix
Change directory before running the script, or use absolute paths inside the script. The cleanest cron command looks like this:
* * * * * cd /home/username/public_html && /opt/cpanel/ea-php81/root/usr/bin/php task.php
The cd changes the working directory, then && runs the PHP command only if the cd succeeds. Now relative includes resolve correctly.
Alternatively, rewrite your script to use __DIR__ for includes:
require_once __DIR__ . '/config.php';
This works regardless of where the script is called from. I recommend it for any script that might run via cron, CLI, or web.
Error 6: Output Spam (Email Overload)
What you see
You set a cron to run every minute. Within an hour you have 60 emails. Most of them contain the same success message or—worse—a verbose debug log from a framework.
Root cause
cPanel sends every line of output as an email. If your script is chatty or runs frequently, your inbox fills up fast. Some users disable email entirely with > /dev/null 2>&1, but then they miss real errors.
The fix
Log output to a file instead of letting it go to email. Append to a log and only email on error:
#!/bin/bash
LOG="/home/username/logs/backup.log"
echo "[$(date)] Starting backup" >> "$LOG"
/usr/bin/mysqldump -u dbuser -p'password' dbname > /home/username/backups/db.sql 2>> "$LOG"
if [ $? -ne 0 ]; then
echo "Backup failed at $(date)" | mail -s "Backup Error" [email protected]
fi
echo "[$(date)] Backup complete" >> "$LOG"
Now the cron produces no output (so no automatic email), but failures trigger a manual alert. Check the log file periodically to confirm everything is running:
tail -f /home/username/logs/backup.log
For PHP scripts, use error_log() to write to a custom log file and only echo on critical failures.
Error 7: Email Not Received (Cron Ran But Inbox Empty)
What you see
You know the cron ran—maybe you see evidence in your application logs—but you never got the email cPanel should have sent.
Root cause
cPanel cron emails go through the local mail system. If your server's hostname isn't properly configured, if your email address is on a remote domain and SPF/DKIM are missing, or if your inbox provider (Gmail, Outlook) is rejecting mail from your server, the email gets lost or lands in spam. On some hosts the default MAILTO variable isn't set at all.
The fix
First, check where cPanel is sending cron mail. In the cPanel Cron Jobs interface, look for the "Cron Email" field at the top. Make sure it contains a valid, working email address—preferably one on the same server so delivery is local.
If emails still don't arrive, SSH in and check /var/log/maillog or /var/log/exim_mainlog (the path depends on your MTA):
grep CRON /var/log/maillog | tail -20
You'll see delivery attempts and any bounce reasons. Common issues: the recipient address doesn't exist, or the remote server rejected the message because your server has no reverse DNS.
For reliable alerts, replace cron's built-in email with an explicit mail command in your script:
echo "Backup completed successfully" | mail -s "Backup Report" [email protected]
Or use a third-party service (SendGrid, Mailgun, or even a Slack webhook) for notifications. That way you're not dependent on the server's mail stack.
Debugging checklist
When a cron job misbehaves, work through these steps in order:
- Check the cron email (if you got one). Read the entire message; the error is usually in the first few lines.
- Run the command manually from SSH using the exact path and arguments from your cron line. If it works in SSH but fails in cron, you have an environment issue (PATH, working directory, PHP version).
- Check file permissions on the script and any files it reads or writes. Use
ls -land confirm the cron user (your cPanel user) can execute and access everything. - Add logging to your script so you can see where it stops. Use
set -xin bash scripts or error_log in PHP. - Verify the cron schedule. Use a tool like crontab.guru to make sure your timing expression means what you think it means.
0 0 * * *is midnight daily;* * * * *is every minute. - Check disk space. Run
df -hand confirm your account isn't full. A full disk causes silent write failures and scripts that quit halfway. - Look at recent changes. Did you update PHP, move the script, or change your database password? Roll back and test.
Most cron failures fit one of the seven patterns above. If you've eliminated all of them and the job still doesn't work, the issue is probably in the script logic itself, not the cron configuration.
What to check first
Start with permissions and paths—they account for 80% of cron failures I see in tickets. Make your script executable, use absolute paths for every command, and change to the correct working directory before running anything. Test the command manually in SSH with the same user and environment cron will use.
Add output to your scripts during development so you get feedback. Once they're stable, redirect output to a log file and set up alerts only for failures. That keeps your inbox clean and gives you a record of what ran when.
cPanel cron jobs are simple—five fields for timing, one field for the command—but the minimal environment catches people off guard. Treat cron like a dumb shell with no memory: spell everything out, assume nothing, and always log what happened. Your 3 a.m. self will thank you when a backup fails and you can see exactly why.
FAQ
How do I test a cron job without waiting for the schedule?
Run the exact command from your cron line in an SSH session. If you don't have SSH, temporarily change the schedule to * * * * * (every minute), wait two minutes, then change it back. Check your email for output.
Can I use ~/ in cron paths?
No. The tilde shortcut for home directory doesn't expand in cron. Use the full path /home/username/ instead.
Why does my cron work in SSH but not in cron?
Environment variables. Your interactive SSH session loads .bashrc or .bash_profile and sets up PATH, aliases, and other variables. cron gets almost nothing. Use absolute paths and set variables explicitly in your script.
How do I stop getting cron emails entirely?
Add > /dev/null 2>&1 to the end of your cron command. But leave it on during troubleshooting—those emails are your only feedback.
What's the difference between * * * * * and */1 * * * *?
Nothing. Both mean every minute. The */1 syntax is redundant but harmless.
Can I run a cron job every 30 seconds?
Not directly. cPanel cron has one-minute resolution. You can run a script every minute that sleeps 30 seconds and runs the task twice, but it's fragile. Use a proper task queue (like Redis/Celery or Laravel Horizon) if you need sub-minute scheduling.