Disable WP-Cron

WP-Cron is WordPress's task list, not a system clock: on each visit, wp-cron.php looks for due events and runs them. A scheduled post, a plugin update check, a backup, or a WooCommerce action such as an unpaid-order timeout all sit on that list. If nobody loads a page, the list waits — which is exactly the behaviour the WordPress developer docs describe when they note WP-Cron is only triggered on page load and missed tasks queue for the next opportunity. If every visit spawns that check, busy sites spend PHP workers on the scheduler instead of the page. The plain-English version of a cron job is in what a cron job is.

• Low traffic: tasks wait for the next visitor, so a post can sit as Missed schedule.
• Cached traffic: a cache hit may never reach PHP, so the check never starts.
• High traffic: every hit can spawn wp-cron.php and queue behind real page requests.

This change turns off WordPress's visitor spawn. It does not delete every cron on the server — a Linux crontab for backups or mail is a different job, covered on the cron explainer linked above. To turn the visitor spawn back on, delete the constant and remove the server job.

On cPanel hosting, create the server job before you touch wp-config.php, because the constant alone leaves scheduled posts and plugin queues waiting with no error. The Cron Jobs screen sits under Advanced in cPanel — WebJi®'s cPanel hosting plans (from ₹297 a month before 18% GST; checkout confirms current charges) include it.

1. In cPanel, open Advanced, then Cron Jobs. Use the login for this domain; the billing screen has no cron form.
2. Add a new job. Pick Once Per Fifteen Minutes, or set Minute to */15 and Hour, Day, Month and Weekday to *.
3. Set Command to wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1, replacing example.com with the address that loads this WordPress site. The tail of the line drops output so cPanel does not mail you on every run.
4. In File Manager, edit wp-config.php in the WordPress folder. Above the stop-editing comment, add define('DISABLE_WP_CRON', true); and save. That line blocks the visit spawn; the cron command can still call the file.
5. Schedule a draft a few minutes ahead. It worked when the post is live after the next run — saving the file alone is not the test.

Fifteen minutes is the default that fits a blog, plugin update checks and a nightly backup. Five minutes serves a post or shop action that should land close to the clock; once an hour leaves scheduled posts late; every minute overlaps on shared hosting.

The doing_wp_cron flag on the URL tells WordPress this request is the direct run; it is not a second scheduler. On a multisite network, one URL runs tasks for that site only, so each other site needs its own cron URL or its events keep waiting.

If the constant is set and tasks still miss, the server job is the thing to fix — the notice that spawning is disabled is expected, not the fault. It becomes a fault only when no cron command calls wp-cron.php.

• Posts still miss: the interval is wider than you need, or the command fails. Read one emailed error before tightening */15 to */5.
• Nothing runs at all: the define line is below the stop-editing comment, or it sits outside the opening PHP tag. Move it above that comment.
• Two runners at once: the constant is missing and a server job also fires, so events overlap. Keep one runner.
• Backups stay idle: the plugin must be set to WP-Cron, not the URL of its own. Check its last-run time after one interval.
• wp-cron.php returns 403: a firewall or an .htaccess rule is blocking the file. The cron mail shows the 403; allow that file for the server call.

If the cron mail shows a path you cannot change, email support@webji.services with the command and the time. The office phone line is not a support queue.