How to Set Up Cron Jobs in cPanel

Cron jobs are scheduled commands that run automatically at set times on your server, without you having to trigger them manually. Common uses include running WordPress's scheduled tasks, sending automated reports, clearing caches, running database maintenance scripts, and executing backups. cPanel gives you a graphical interface for managing them without touching a terminal.

Finding Cron Jobs in cPanel

Log into cPanel and scroll to the Advanced section. Click Cron Jobs. At the top you'll see an option to set your cron email, this is the address where output from your cron commands gets sent. Set this to an address you check regularly.

You can also suppress email output entirely by redirecting it to /dev/null in the command itself (shown below). Below the email field is the "Add New Cron Job" form with dropdown helpers for common intervals (Once Per Minute, Once Per Hour, Once Per Day, etc.) and input fields for the full crontab schedule.

Understanding Crontab Syntax

Every cron job is defined by five time fields followed by the command to run:

# minute  hour  day-of-month  month  day-of-week  command
  *        *     *             *      *            /path/to/command

# Run every hour at minute 0:
  0        *     *             *      *            /usr/bin/php /home/user/script.php

# Run every day at 3am:
  0        3     *             *      *            /usr/bin/php /home/user/backup.php

# Run every 15 minutes:
  */15     *     *             *      *            curl -s https://yourdomain.com/ping

# Run every Monday at 8am:
  0        8     *             *      1            /usr/bin/php /home/user/weekly-report.php

The asterisk * means "every". */15 in the minute field means "every 15 minutes". cPanel's dropdown helpers fill these fields automatically if you don't want to write the syntax manually, select your interval from the "Common Settings" dropdown and it populates the fields for you.

Day-of-week values: 0 = Sunday, 1 = Monday, 2 = Tuesday, and so on through 6 = Saturday. Day-of-month values are 1–31. If both day-of-month and day-of-week are specified (not asterisks), the job runs when either condition is met.

WordPress Cron and Why You Should Replace It

WordPress has its own scheduling system called WP-Cron. It doesn't run on a real server schedule, it runs when someone visits your site. If no one visits for hours, scheduled tasks (publishing posts, sending emails, running plugin tasks like scheduled backups) don't fire on time. On low-traffic sites, this causes noticeable delays and unreliable scheduling.

The fix is to disable WP-Cron's built-in trigger and replace it with a real server cron job. First, add this to your wp-config.php:

define( 'DISABLE_WP_CRON', true );

Then in cPanel Cron Jobs, create a new job that runs every 5 minutes using cURL:

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

The > /dev/null 2>&1 part suppresses all output so you don't get emailed on every run. This approach ensures WordPress tasks fire reliably and removes the performance overhead of WP-Cron triggering on every page load on high-traffic sites.

Running PHP Scripts Directly

If you want to run a PHP script directly via the CLI rather than via a web request, use the full path to the PHP binary. Find your server's PHP path by running which php in SSH, or ask your host. It's typically /usr/local/bin/php or /usr/bin/php.

0 2 * * * /usr/local/bin/php /home/username/scripts/cleanup.php

Note the difference between running a script via the CLI PHP binary and running it via a web request (curl). CLI PHP doesn't load your web server configuration or respect .htaccess rules, but it also isn't subject to web server timeouts. For long-running scripts, CLI PHP is the better choice, it can run for hours without hitting a max_execution_time limit.

The PHP binary used by the CLI and the one used by the web server may also be different versions. On a cPanel server with CloudLinux and PHP Selector, the CLI PHP might be the system PHP while your site uses a user-selected version. To ensure the cron runs the same PHP version as your site, use the specific versioned binary path: /opt/cpanel/ea-php82/root/usr/bin/php (for PHP 8.2 on cPanel EasyApache 4).

Getting Output by Email and Logging

To receive the script's output by email, set the cron email address at the top of the Cron Jobs page in cPanel. Any output printed by your script will be emailed after each run. This is useful during initial setup and testing, once you're satisfied the job is running correctly, suppress output with > /dev/null 2>&1 at the end of the command to avoid filling your inbox.

A better alternative to email for debugging is logging to a file:

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

The >> appends to the log file rather than overwriting it. Check the log periodically and clear it when it grows large. Including a timestamp in your script's output makes the log useful for diagnosing timing issues.

Common cron job use cases for WordPress sites

Beyond the WP-Cron replacement, several common tasks benefit from server-side scheduling:

Daily database backup: Export the database to a file nightly, then transfer to cloud storage. Run via WP-CLI (wp db export) or a direct mysqldump command.

Image optimisation queue: If you use a server-side image optimisation tool, run the optimisation queue via cron during off-peak hours rather than triggering it on every upload.

Log rotation: If your application generates log files, a cron job that compresses and archives logs weekly keeps disk usage under control.

Cache warming: After a cache flush, a cron-triggered crawler can pre-warm your most important pages by hitting them with a curl request, so the first real visitor doesn't wait for an uncached page load.