Replace WP-Cron with a hosting cron job

WordPress uses WP-Cron to run pending events, such as scheduled posts and plugin tasks. Usually, visits help trigger them. This keeps installation simple, but a low-traffic website may run tasks late and a very busy website may prefer a system trigger.

This is not about removing the tasks, but about changing how they start. Disabling WP-Cron without a working replacement can leave posts, emails or shop operations pending.

Option with Softaculous

In WordPress Manager by Softaculous, find the right installation and the WordPress Cron (wp-cron.php) option. Softaculous offers to disable the visit trigger and replace it with a system task.

Then check Cron Jobs in cPanel: make sure the job has been created, which installation it runs and how often. The mode documented by Softaculous may be hourly; do not assume it is suitable for tasks that must run every few minutes. Do not add another equivalent job if one already exists.

See the official Softaculous manager for the features in your version and test a scheduled event before considering the change finished.

Manual setup

Keep a copy of wp-config.php and review the existing jobs. From cPanel Cron Jobs, prepare a job with the frequency the application needs. Every five minutes can be a starting point, but it does not guarantee to-the-second accuracy or that a long task has finished before the next one.

If you use an HTTPS request, first test this command with the real WordPress domain and path:

curl --fail --silent --show-error --max-time 60 --output /dev/null 'https://tudominio.com/wp-cron.php?doing_wp_cron'

Check that it does not return a redirect, login page, firewall challenge or cached copy. The command does not follow redirects: use the correct final URL. The client's timeout does not prove that the work on the server has stopped.

If WordPress is in a subdirectory, include it. In the cPanel form, the date and time fields are separate from the command; do not paste a full crontab line there if it only asks for the command.

Once the replacement is tested and scheduled, add this to wp-config.php, before WordPress loads:

define('DISABLE_WP_CRON', true);

If the constant already exists, change its value without duplicating it. The WordPress procedure explains this change of trigger.

Check tasks and avoid duplicates

Check a scheduled test post and the important events of your plugins. Look for overdue tasks and errors. A successful HTTP response does not guarantee that every callback has finished without failures.

If you prefer to run events with WP-CLI, check the path, PHP version, site context and concurrency policy with the developer. Do not keep several equivalent Softaculous, HTTP and WP-CLI jobs at the same time.

If something fails, restore the previous trigger and remove or pause the replacement that does not work. Do not leave DISABLE_WP_CRON active while you investigate without another way of running the events. On multisite, check the needs of each site in the network.