Hosting & cPanel — Set Up a Real WordPress Cron Job in cPanel

WordPress uses WP-Cron to handle scheduled work, including publishing posts, checking for updates, processing WooCommerce tasks and sending automated emails. By default, WP-Cron is triggered when someone loads your website rather than by a continuously running background service.

That arrangement is convenient, but it can cause delays on low-traffic sites. Busy websites can also receive several requests that try to start cron at once. A server cron job gives WordPress a more predictable schedule and does not depend on visitors.

This guide explains how to disable the normal visitor-based trigger and configure a real WordPress cron job through cPanel.

Why use a server cron job for WordPress?

WP-Cron checks for due events during a page request and then attempts to run them. If nobody visits the site, scheduled tasks may wait. Caching, security software and high traffic can also affect how reliably the process starts.

A server cron job runs at the interval configured in your hosting account, whether or not the site has visitors. It can be useful for:

• Scheduled WordPress posts
• WooCommerce orders, subscriptions and other background tasks
• Membership, booking and email plugins
• Automated content workflows
• Database cleanup and maintenance
• Sites with low traffic or aggressive caching

If your site is already showing missed schedules or cron errors, start with How to Fix WordPress Cron Jobs for broader troubleshooting steps.

What you need before starting

You will need access to cPanel, permission to create cron jobs and the absolute path to your WordPress installation. It also helps to know which PHP binary your hosting provider expects for command-line tasks.

A typical WordPress path might be:

/home/username/public_html

An addon domain or subdomain may use a path such as:

/home/username/example.com

Do not copy either path without checking. In cPanel’s File Manager, open the directory that contains wp-config.php. That directory is the WordPress path you need.

Step 1: Disable the visitor-based WP-Cron trigger

When a server cron job will handle scheduling, disabling the default trigger prevents WordPress from attempting to launch cron during ordinary page requests. It also avoids having two mechanisms run the same process.

Open File Manager in cPanel and locate wp-config.php in the WordPress root directory. Download a backup or make a copy before editing the file. Add this line above the comment that says WordPress should stop editing:

define( 'DISABLE_WP_CRON', true );

It should appear before:

/* That's all, stop editing! Happy publishing. */

This setting does not remove scheduled events. It only stops the usual page-load trigger. The server cron job will still run WordPress’s cron system.

Step 2: Open Cron Jobs in cPanel

Return to the cPanel home screen and open Cron Jobs, which is commonly listed under Advanced. Your hosting provider may use a customized layout, so the location can differ.

Look at the Cron Email field before creating the job. During testing, an email address can help you notice command errors. Once the job is working, you can redirect output to a log file or use /dev/null if you do not need routine notifications.

Step 3: Add the WordPress cron command

For many hosting accounts, the simplest approach is to run WordPress’s built-in wp-cron.php file with PHP:

/usr/local/bin/php -q /home/username/public_html/wp-cron.php > /dev/null 2>&1

Replace username and public_html with the values for your account.

The PHP executable is not the same on every server. Common examples include:

/usr/local/bin/php
/usr/bin/php
/opt/cpanel/ea-php82/root/usr/bin/php

Your host may use another path or PHP version. If the command fails, ask hosting support for the correct command-line PHP binary. It should normally be compatible with the PHP version assigned to your domain.

Step 4: Select a schedule

Every five minutes is a reasonable starting point for many WordPress sites. You can select Every 5 Minutes from cPanel’s preset menu or enter the following values manually:

Minute	Hour	Day	Month	Weekday
*/5	*	*	*	*

This runs the command every five minutes. A site with fewer scheduled tasks may only need an interval of ten or fifteen minutes. Running a resource-intensive task every minute can create unnecessary load, particularly on shared hosting.

Try to leave enough time for one run to finish before the next begins. Overlapping executions can consume additional resources and may cause problems for long-running tasks.

Step 5: Save and test the cron job

Click Add New Cron Job to save the entry. cPanel accepting the form only confirms that the schedule was stored; it does not prove that the command can run successfully.

If your hosting plan provides Terminal or SSH access, test the command from the WordPress directory:

/usr/local/bin/php -q wp-cron.php

A successful run may produce no output. For troubleshooting, temporarily redirect the output to a log file:

/usr/local/bin/php -q /home/username/public_html/wp-cron.php >> /home/username/cron.log 2>&1

After the scheduled run, inspect cron.log for PHP errors, incorrect paths or permission problems. Delete the log or restrict its permissions after testing because it may contain server information.

Alternative method: run cron with WP-CLI

If WP-CLI is available on your hosting account, you can run only the events that are due:

cd /home/username/public_html && wp cron event run --due-now > /dev/null 2>&1

Some hosts require the full path to WP-CLI, such as /usr/local/bin/wp. WP-CLI is useful for command-line administration, but it is not installed on every shared hosting plan. The PHP command is usually the simpler option.

Common problems and solutions

Scheduled tasks are still running late

Check the WordPress path, PHP path and file permissions. Confirm that DISABLE_WP_CRON is spelled correctly and placed inside wp-config.php before the stop-editing comment. Also make sure the cron job runs under the same hosting account that owns the site.

The command reports a PHP version error

Command-line PHP may use a different version from the one configured for your domain. Ask your host for the matching PHP binary, including the correct EasyApache path if applicable.

cPanel sends unwanted cron email

After testing, append > /dev/null 2>&1 to suppress normal and error output. During troubleshooting, use a protected log file instead so failures remain visible.

A plugin still reports cron problems

Some plugins rely on loopback requests or have separate scheduling requirements. Check whether the expected cron events are being registered and review the plugin’s documentation. Custom code can also introduce scheduling issues; How to Create a Custom WordPress Plugin provides related development context.

Setup checklist

• Back up wp-config.php.
• Confirm the absolute path to the WordPress installation.
• Add DISABLE_WP_CRON above the stop-editing comment.
• Confirm the correct command-line PHP path with your host if necessary.
• Choose an interval of five to fifteen minutes based on the site’s workload.
• Test with a temporary log file.
• Monitor scheduled posts and plugin tasks for several days.

Frequently asked questions

Does disabling WP-Cron delete scheduled posts?

No. It only stops WordPress from triggering cron during page requests. The scheduled events remain in WordPress and can run when the server calls wp-cron.php.

Should the job run every minute?

Usually, no. Every five minutes works for many sites. Use a shorter interval only if a plugin or business process needs it and the hosting environment can support the additional executions.

Can I call wp-cron.php with a web URL?

Some hosts allow a cron command using wget or curl, but a local PHP command avoids depending on HTTP, SSL and firewall behavior. Ask your host which method it supports.

What if Cron Jobs is missing from cPanel?

Your provider may have disabled the feature for your hosting plan. Contact support and ask whether they can create a server cron job for the WordPress installation.

Conclusion

A real cPanel cron job makes WordPress scheduling less dependent on traffic, caching and page requests. Back up wp-config.php, disable the visitor-based trigger, use the correct PHP and WordPress paths, choose a sensible interval and test the command before relying on it. Monitoring scheduled tasks afterward will help reveal plugin-specific issues that the cron configuration alone cannot fix.