How to Set Up and Troubleshoot Cron Jobs in cPanel

You set up a cron job in cpanel" class="auto-link">wordpress-missing-a-temporary-folder-upload-error" class="auto-link">cPanel six months ago to email you a daily database backup, or clear a cache folder, or run a WordPress maintenance script. It worked fine for a while. Then one day you notice the backups stopped, or a report you rely on hasn't shown up in your inbox in weeks — and cPanel gives you no warning when a cron job quietly breaks. Here's how to set them up correctly and how to track down why one has gone silent.

What a Cron Job Actually Does

Cron is the Linux task scheduler. It runs a command at a time you specify, every time, without you touching anything. On a SkyServer cPanel account you get access to it through cPanel > Advanced > Cron Jobs — no SSH needed, though SSH works too if you're on a VPS with root access.

Typical uses we see from customers:

• Running wp-cron.php on a real schedule instead of relying on WordPress's page-load trigger
• Nightly database or file backups via a script
• Clearing temp/cache directories that build up over time
• Pulling data from an API on a schedule
• Sending scheduled reports by email
• Renewing tokens or refreshing session data for a custom app

Setting Up a Cron Job in cPanel

Log in to cPanel, open Cron Jobs under the Advanced section, and you'll see two things: a common settings dropdown for quick schedules, and five fields for minute, hour, day, month, and weekday if you want a custom schedule.

A basic PHP script run every day at 2:30 AM looks like this in the command field:

/usr/local/bin/php /home/username/public_html/scripts/backup.php

And the schedule fields would be:

A few things trip people up on the command line itself:

• Always use the full path to the interpreter. Don't write php script.php — write /usr/local/bin/php script.php. Cron doesn't load your shell's PATH, so a bare php or python3 often just fails silently.
• Use the full path to the script too. /home/username/public_html/scripts/backup.php, not a relative path. Cron's working directory is not your home folder.
• Check the PHP version. If your script needs PHP 8.1 but the CLI default on the server is 7.4, it'll either error out or behave unexpectedly. Run /usr/local/bin/php -v via SSH, or use the version-specific binary cPanel exposes, something like /usr/local/bin/ea-php81.

Symptom: The Job Stopped Running, No Error Anywhere

This is the most common ticket we get. Nothing in the cPanel interface tells you a cron job failed — it just doesn't show up as having run. Here's the order we check things in.

1. Check if it's actually configured to email output

By default, cPanel's cron system tries to email the job's output (including errors) to the account's contact email. If that field is blank or pointing at a dead inbox, you lose your only built-in error signal. Go to Cron Jobs > Cron Email and make sure a working address is set. If you'd rather not get an email every single run, redirect output to a log file instead:

/usr/local/bin/php /home/username/scripts/backup.php >> /home/username/logs/backup.log 2>&1

That 2>&1 at the end captures errors along with normal output, and >> appends rather than overwriting, so you keep a running history.

2. Look for a silently failing script, not a silently failing cron

Nine times out of ten, cron itself is running fine — it's the script that's dying. Common causes:

• A hardcoded absolute path inside the script that changed after a migration (this happens a lot after moving accounts to SkyServer — the username or home directory path can differ from the old host)
• A database credential in the script that's out of date after a password reset
• A PHP memory limit too low for what the script is trying to do
• File permissions blocking the script from reading or writing where it needs to

Run the exact command manually via SSH or the cPanel Terminal and watch what happens:

/usr/local/bin/php /home/username/public_html/scripts/backup.php

If it errors out on the command line, you've found your problem. If it runs fine manually but not on schedule, the issue is almost always environment differences — cron runs with a much more minimal environment than an interactive shell.

3. Check the system cron log

On a VPS with root access, /var/log/cron (or grep CRON /var/log/syslog on some distros) shows whether the cron daemon actually triggered the job at all. If the job doesn't appear there, the schedule itself is misconfigured — usually a typo in the minute/hour fields, or the job got accidentally deleted in a cPanel update or account restore.

4. Watch out for overlapping runs

If a job normally finishes in 2 minutes but occasionally hangs — a slow API call, a database lock — and you've scheduled it every 5 minutes, you can end up with two or three copies running at once, fighting over the same files or locking the same database rows. Add a simple lock file check at the top of the script, or use flock in the cron command itself:

flock -n /tmp/backup.lock /usr/local/bin/php /home/username/scripts/backup.php

This makes sure a new run won't start until the previous one has actually finished.

The Special Case: WordPress Cron

WordPress ships with its own pseudo-cron, wp-cron.php, which by default only fires when someone visits the site. On a low-traffic site that means scheduled posts publish late, plugin update checks lag, and scheduled backups skip. The fix is to disable WP's built-in trigger and hand scheduling to real system cron instead.

In wp-config.php, add:

define('DISABLE_WP_CRON', true);

Then create a cron job in cPanel to hit it every 15 minutes:

wget -q -O /dev/null "https://yourdomain.com/wp-cron.php?doing_wp_cron"

This is more reliable than the default behavior and takes the load off random visitor page requests. It's a small change, but it fixes a surprising number of "scheduled post didn't publish" and "backup plugin skipped a day" complaints.

Prevention: Make Cron Failures Loud, Not Silent

A cron job that fails quietly is worse than one that fails loudly, because you find out weeks later when something important didn't happen. A few habits that save a lot of pain:

• Log every run, even successful ones, with a timestamp — makes it obvious at a glance when something last worked
• If a script's job is critical (backups, invoicing, report generation), have it write a "last successful run" timestamp somewhere you can check, or ping a monitoring service on success
• Test any new cron command manually first, exactly as it will run, before scheduling it
• Review your cron list every few months — old jobs from decommissioned scripts or previous developers pile up and quietly waste server resources or fail forever

If you're not sure whether a job on your SkyServer account is actually running, our support team can pull the cron execution logs from the server side and tell you exactly what's happening — that's usually faster than guessing from the cPanel interface alone.

Frequently Asked Questions

Why does my cron job work when I run it manually but not on schedule?

Cron runs with a minimal environment — no shell profile, no PATH variables you might rely on interactively, and a different working directory. Always use full absolute paths for both the interpreter and the script, and avoid relying on environment variables that only exist in your interactive SSH session.

Can I run a cron job more often than once a minute?

No, one minute is the shortest interval cron supports. If you need something closer to real-time, you'd typically run a persistent background process or daemon instead, which is a VPS-level setup rather than a shared hosting cron job.

Will a cron job survive if I migrate my account to a new server?

Cron job entries themselves usually transfer with a full cPanel account migration, but always double-check the schedule after moving. Hardcoded paths inside your scripts are the more common breakage — if the new account has a different username or directory structure, absolute paths inside the script need updating even if the cron entry itself looks correct.

How do I stop getting a flood of emails from a cron job?

Redirect the script's output to a log file instead of letting cPanel email it by default: append >> /path/to/logfile.log 2>&1 to the end of the command. You'll still have a record to check, just not an inbox full of routine run notifications.

My cron job is set to run "every 5 minutes" but I only see it once an hour. Why?

Check the minute field wasn't set to a single value like 0 combined with an hour range, which only fires once per hour. For every 5 minutes, the minute field should be */5, with hour, day, month, and weekday left as *.