Confirm whether the service or a management tool already runs WordPress cron. Adding another runner without checking can create duplicate or overlapping work. Review the required timing for scheduled posts, emails and commerce jobs.

Identify the correct installation path, hosting user and supported PHP or WP-CLI executable. A command that works in an interactive shell may use a different environment from the scheduler.

1. Choose one supported method: a scheduled HTTPS request to wp-cron.php or an appropriate command-line runner.
2. Configure the task through the service's scheduled-task interface using the actual paths and a reviewed interval.
3. Retain useful output or error reporting during initial testing rather than discarding every failure.
4. Run a controlled test and inspect the event list and logs to confirm due work is processed.
5. Only after the replacement is verified, add or update the following setting in the correct wp-config.php:

define('DISABLE_WP_CRON', true);

Where WP-CLI is supported, the relevant operation is wp cron event run --due-now --path=/path/to/wordpress, with the correct executable and installation path. This runs due callbacks and can perform real business actions, so test it deliberately. Do not copy a placeholder path into a live scheduler.

For an HTTPS trigger, confirm the request reaches WordPress without a login challenge, redirect loop or certificate error. Do not disable TLS verification to hide a routing problem.

For a single-site installation with authorised WP-CLI, local flock and an approved five-minute interval, a scheduler entry can look like this. Replace the interpreter, account and private paths with the service’s real values before enabling it.

*/5 * * * * /usr/bin/flock --nonblock /home/ACCOUNT/private/wp-cron.lock /usr/local/bin/wp --path=/home/ACCOUNT/sites/example.com --url=https://example.com cron event run --due-now >> /home/ACCOUNT/private/wp-cron.log 2>&1

Due events execute real callbacks, so first verify this arrangement with a controlled staging task and check for an existing managed runner. The local lock prevents this launch path from overlapping itself; it does not coordinate other servers. Keep useful logs while testing.

Expected result: Due work completes at the intended interval without competing copies. Only after the replacement is confirmed should the normal visitor-trigger setting be disabled. A failed replacement has a documented route back to the previous working scheduler.

Choose an interval longer than the normal execution time or use an appropriate supported locking approach when needed. Heavy jobs should not accumulate faster than the site can process them. Review errors and overdue events over several intervals.

A command-line runner can use a different PHP configuration from the web application, so confirm required extensions and compatibility. On Multisite, plan the site scope rather than assuming one command covers every network queue as intended.

Test a scheduled post or other controlled workflow and confirm its actual result. If the replacement fails, restore the intended default trigger while correcting the job, and remove obsolete duplicate scheduler entries.

Document the owner, interval, command location and monitoring route. Disabling visitor-triggered cron without a functioning replacement can silently stop publication, notifications and maintenance, even though ordinary pages continue to load.

• Checking WordPress cron events with WP-CLI
• Finding why scheduled posts missed publication
• Troubleshooting failed loopback requests
• Checking WordPress core file integrity with WP-CLI

• WordPress: Hooking WP Cron Into The System Task Scheduler
• WordPress: Run
• WordPress: WP Config

• util-linux flock command