A cron job runs a command or script automatically on a schedule — clearing a cache every night, sending a scheduled report, or triggering a WordPress task without relying on site visits.
Understanding cron syntax
A cron schedule is five fields: minute, hour, day of month, month, day of week. 0 3 * * * means “at 3:00 AM every day”; */15 * * * * means “every 15 minutes”; 0 0 1 * * means “midnight on the first of every month”.
Creating a cron job in cPanel
- Go to Advanced > Cron Jobs.
- Under “Add New Cron Job”, either pick a common schedule from the dropdowns or select “Common Settings” for presets like “Once Per Day”.
- Enter the command to run — for a PHP script, this is typically
php /home/username/public_html/script.php; for a URL-based trigger,wget -q -O /dev/null "https://yourdomain.com/cron-task.php". - Click Add New Cron Job.
PHP scripts vs URL triggers
Running a script directly via the php command (CLI) avoids web server overhead and doesn’t count against HTTP request logs, but the script runs in a command-line PHP context, so it can’t rely on things like $_SERVER['HTTP_HOST'] being set the way it is on a normal page load. Triggering via wget/curl against a URL runs it exactly like a real page load, which is sometimes required by scripts (like WordPress’s own wp-cron.php) written to expect that context.
WordPress specifically
WordPress’s default “cron” only runs when someone visits the site, which is unreliable on low-traffic sites. Disabling that (define('DISABLE_WP_CRON', true); in wp-config.php) and instead adding a real cPanel cron job hitting wp-cron.php every 15 minutes makes scheduled posts, plugin tasks, and backups run reliably regardless of traffic.
Checking it actually ran
cPanel emails the cron’s output to your account’s contact email by default, which gets noisy fast — redirect output to /dev/null (append > /dev/null 2>&1 to the command) once you’ve confirmed it works, and instead have the script itself log to a file if you need an audit trail.