Cron Jobs in cPanel: Setup, Syntax, and Common Fixes

If you've ever set up a cron job in cPanel and then wondered why it never ran - or ran ten times in a row - you're not alone. Cron syntax looks simple until it isn't, and cPanel's UI hides a couple of gotchas that trip up even experienced admins.

What a Cron Job Actually Does

A cron job is just a scheduled command that the server runs on its own, on a timetable you set. No browser tab needs to stay open, no plugin needs to "wake up" - the system clock triggers it directly. In cPanel, this is exposed as a simple form under Advanced → Cron Jobs, but under the hood it's writing a line into the account's crontab file.

Typical uses on a hosting account:

• Running a real WordPress cron instead of relying on site-visit-triggered wp-cron.php
• Nightly database backups or export scripts
• Clearing a cache directory or temp uploads folder
• Hitting a URL to refresh an external feed or API sync
• Rotating logs so they don't eat your disk quota

Setting One Up in cPanel

Log in to cPanel and go to Advanced → Cron Jobs. You'll see two things: a set of dropdowns for common schedules, and a raw command box. Here's the process:

1. Pick a schedule using the dropdowns (minute, hour, day, month, weekday) - or use the "Common Settings" preset for things like "Once Per Day".
2. Paste the command into the Command field.
3. Click Add New Cron Job.

For a PHP script you want run once a day at 2 AM, the command usually looks like this:

/usr/local/bin/php -q /home/yourcpanelusername/public_html/scripts/cleanup.php

Two details matter here that people skip: use the full path to PHP (cron doesn't load your shell's PATH the way SSH does), and use the full path to the script, starting from /home/yourcpanelusername/. A relative path that works fine when you run it manually over SSH will silently fail under cron because cron's working directory isn't your home folder.

To find the exact PHP path on your account, run this once over SSH or through Terminal in cPanel:

which php
# or, if you're on a MultiPHP setup:
/usr/local/bin/ea-php81 -v

Reading Cron Syntax Without Guessing

The raw crontab line has five time fields, always in this order:

* * * * * command
| | | | |
| | | | +-- day of week (0-6, Sunday=0)
| | | +---- month (1-12)
| | +------ day of month (1-31)
| +-------- hour (0-23)
+---------- minute (0-59)

A few real examples that come up constantly:

Note that cPanel's server time zone (usually UTC or the data center's local time, shown at the bottom of the Cron Jobs page) is what the schedule runs on - not your browser's time zone. If your job fires three or five hours off from what you expected, that's almost always the reason.

Cron vs WP-Cron: Why WordPress Sites Need Real Cron

By default, WordPress doesn't use the system's cron at all. It uses wp-cron.php, which only fires when someone loads a page on your site - a visitor request triggers a background check of "is anything scheduled to run now?" That works fine on high-traffic sites, but it causes two problems on lower-traffic ones:

• Scheduled posts publish late because nobody visited the site at the exact publish time.
• Backup and SEO plugins skip their scheduled tasks, or bunch several tasks into one slow page load, which visitors feel as a random slowdown.

The fix is to disable WordPress's built-in trigger and replace it with a real cPanel cron job that hits wp-cron.php directly on a fixed schedule. Add this to wp-config.php, above the line that says /* That's all, stop editing! */:

define('DISABLE_WP_CRON', true);

Then create the cron job in cPanel to run every 15 minutes:

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

If wget isn't available on your plan, use curl instead:

*/15 * * * * curl -s "https://yourdomain.com/wp-cron.php?doing_wp_cron" > /dev/null 2>&1

This takes the scheduling off visitor traffic entirely and runs it on a predictable clock, which is exactly what you want for scheduled publishing, backup plugins, and SEO sitemap regeneration.

When a Cron Job "Isn't Running"

Nine times out of ten, the job actually is running - it's just failing silently or the output is going nowhere you can see. Work through these in order:

1. Check if cPanel is actually emailing you the output

By default, cPanel emails the cron's output (stdout/stderr) to the account's contact email every time it runs. If you're not seeing anything, that usually means the command produced no output and exited fine - not that it didn't run. To confirm either way, redirect output to a log file temporarily:

/usr/local/bin/php -q /home/user/public_html/scripts/cleanup.php >> /home/user/cron.log 2>&1

Then check the file after the next scheduled run to see the real error, if any.

2. Verify the PHP path and script path are both absolute

This is the single most common cause of "nothing happens." A script that works when you type php cleanup.php from inside the folder over SSH will fail under cron if the command in cPanel just says php cleanup.php with no path.

3. Check file permissions

The cron job runs as your cPanel user, so the script needs to be readable (and executable, if it's a shell script) by that user. 644 is fine for a PHP file called via the PHP binary; a standalone shell script needs 755.

4. Check for a full disk or suspended cron

If the account's disk quota is exceeded, cron jobs can fail to write their log or lock files and silently stop. Check disk usage in cPanel's main dashboard, and confirm cron itself isn't paused - some shared hosting plans let support staff disable cron per-account if a script is misbehaving and hammering the server; if you genuinely can't find a reason it's not firing, that's worth a quick check with support.

5. Test the exact command manually

Copy the command straight out of the Cron Jobs list and run it manually over SSH, exactly as written, including the full paths. If it errors there, cron will hit the same error - you've just found it faster.

Prevention: Keep Cron Jobs From Becoming a Problem Later

• Always use absolute paths for both the interpreter and the script.
• Redirect output somewhere useful (a log file) instead of letting years of "cron job completed" emails pile up in an inbox you stopped checking.
• Avoid scheduling anything more often than it needs - a script hitting every minute that takes 90 seconds to run will start overlapping itself and can spike CPU.
• Rotate or truncate any log files your cron jobs write to, or they'll quietly fill the disk over a few months.
• Document what each cron job does somewhere outside cPanel - six months later, "run.sh" tells you nothing.