wp-cron stampedes that look like traffic

A wp-cron stampede happens when every page visit starts wp-cron.php while a real crontab is already running the same jobs. The Metrics graph can look like bot traffic because CPU rises with hits, and those hits are often your own cron loop. Disable the on-request runner, then schedule one crontab every five minutes so WordPress has a single owner for scheduled work.

WordPress turns on the visit-triggered runner by default because it is convenient on a laptop. On a live shop that pattern becomes overlapping PHP, duplicate emails, double stock changes, and queue workers fighting each other. More cron is not more reliability when the jobs race.

Turn off the on-request runner

Add this line to wp-config.php so visits stop spawning cron:

define(‘DISABLE_WP_CRON’, true);

After that change, only your scheduled job should fire due events. If the define never lands, or a second wp-config still leaves it false, visits will keep starting the fake runner and the stampede continues.

Schedule one real crontab

Use cPanel cron on shared hosting, or a normal crontab on a VPS. Run due events every five minutes with WP-CLI when you have it:

*/5 * * * * cd $HOME/public_html && wp cron event run –due-now >/dev/null 2>&1

If you prefer HTTP, curl wp-cron.php once from that same crontab and redirect the output. Do not also hit that URL from uptime monitors while the default runner is still enabled. Log the real cron job so you can see whether it actually runs.

Keep a single clock

Action Scheduler, WooCommerce, and backup plugins all share the same event loop. If a five-minute run lasts longer than the interval, you have too much queued work, not too little cron. Do not add a second job at */2 to catch up, because the jobs will overlap and recreate the stampede.

On shared hosting, cPanel cron is the scheduler you get. On a VPS, do not also add a systemd timer for the same wp-cron.php path. One owner and one cycle make the Metrics graph easier to read. Backup plugins that fire their own HTTP cron every two minutes belong on the same diet: run wp cron event run --due-now and the backup CLI from one system crontab, spaced apart, and lengthen the interval if a job still overruns.

When only one clock remains, the rectangle that looked like bots either calms down or you truly have outside traffic, which is a separate problem to chase.