How to Set Up Cron Jobs in cPanel for WordPress and Laravel

A cron job runs a command on a schedule: every five minutes, every night, on the first of the month. On a cPanel account, cron jobs drive a lot of the work behind WordPress and Laravel sites, including scheduled posts, queued emails, cache clearing and backups. A cron job that fails silently is worse than none, because the site looks fine until a task that mattered stops running. This guide shows how to create cron jobs in cPanel, how to choose the right PHP binary, how to replace WordPress’s built-in cron with a real schedule, and how to check that each job actually runs.

On SiteHarbour’s cPanel hosting plans you can create cron jobs from your own cPanel, so you can run these jobs without a server administrator. The steps are the same on any cPanel host.

How cron works in cPanel#

A cron line has five time fields, then the command. The fields are minute, hour, day of month, month and day of week. This example runs a script every 15 minutes:

*/15 * * * * /usr/local/bin/php ~/public_html/cron.php > /dev/null 2>&1

The redirect at the end throws away the output so the account does not send an email for every run. It hides errors, too, so use a log file for any job you depend on, as shown in Step 4.

Step 1: Find the right PHP binary#

The php command on your PATH may not be the version your site uses. Check which PHP version the domain runs in Select PHP Version or MultiPHP Manager, then find the matching binary over SSH:

ls /opt/cpanel/ea-php84/root/usr/bin/php
/opt/cpanel/ea-php84/root/usr/bin/php -v

Use ea-php83, ea-php82 and so on for other versions. Expected: the version line matches the one you chose for the domain. Use the full path in the cron command so the job always runs the same PHP.

Step 2: Create the job in cPanel#

Open Cron Jobs in cPanel. Choose a common schedule from the list, or set the minute, hour and day fields by hand, then paste the command. Use the full path to the PHP binary and to the script. Select Add New Cron Job.

Expected: the job appears in the list with its schedule shown in plain words. Check that the schedule matches what you meant, because 0 * * * * runs hourly, not daily.

Step 3: Replace WordPress’s built-in cron#

WordPress runs its scheduled tasks when someone visits the site. On a quiet site, scheduled posts and cleanup tasks then run late or not at all. For a reliable schedule, turn off the visitor-triggered version in wp-config.php, above the line that says to stop editing:

define('DISABLE_WP_CRON', true);

Then add a cron job that calls the WordPress cron file every 5 minutes:

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

Expected: scheduled posts publish within a few minutes of their time. If curl is not installed on the account, use wget -q -O /dev/null with the same URL.

Step 4: Log what the job does#

Send the output to a log file, with a time stamp, so you can see what ran and what failed:

*/15 * * * * /opt/cpanel/ea-php84/root/usr/bin/php ~/public_html/cron.php >> ~/logs/cron.log 2>&1

Create the folder first with mkdir -p ~/logs. Read the log after the first run:

tail -n 20 ~/logs/cron.log

Expected: no PHP errors and a line from your script. Keep the log short with a weekly check, because it grows over time.

Step 5: Make the job safe to overlap#

If a job takes longer than its interval, a second copy starts while the first is still running. Two copies of a backup or a mail queue run can corrupt data. Use flock, which exits if the lock is taken:

*/15 * * * * flock -n ~/cron.lock /opt/cpanel/ea-php84/root/usr/bin/php ~/public_html/cron.php >> ~/logs/cron.log 2>&1

Expected: a run that starts while another is still going exits at once, and the first run finishes alone.

Step 6: Check that it runs#

Add a temporary job that writes the time to a file every minute, to confirm cron works on the account. Look at the file after two minutes, then delete the job and the file. This is the quickest test, and it separates a broken schedule from a broken script.

Common mistakes#

• Using the wrong PHP. A job that runs an older PHP can fail on syntax that the site accepts.
• Relative paths. Cron runs from the home folder, not the site folder. Use full paths for everything.
• Silent output. Redirecting everything to /dev/null hides the errors you need to see.
• Overlapping runs. Use flock for any job that can run long.
• Leaving the visitor cron on. With DISABLE_WP_CRON off and a system cron also running, tasks can run twice.

Frequently asked questions#

How often should a cron job run?#

As often as the task needs, and no more. WordPress scheduled posts work well every five minutes. Heavy jobs, such as backups, belong overnight.

Why did my cron job stop working?#

Often the script path changed, the PHP version was removed, or the account exceeded a resource limit. Check the log, then the path, then the account’s resource usage. Limits are explained in how to fix the 508 Resource Limit Is Reached error on cPanel.

Can a cron job run a Laravel scheduler?#

Yes. Run the Laravel scheduler once a minute with php artisan schedule:run, using the full PHP path and the application folder. The scheduler decides which tasks are due.

Is there a limit to the number of cron jobs?#

Your plan may limit them. Keep only the jobs you need, and combine tasks that run on the same schedule.

A cron job is simple once you know the three things that go wrong: the wrong PHP, a path that depends on where cron starts, and output that nobody reads. Pick the right binary, use full paths, write to a log, and protect long jobs with a lock. For the Laravel side of a cPanel deployment, read how to deploy Laravel on cPanel shared hosting.