Architecture Note: Decoupling WordPress WP‑Cron from Visitor Traffic

Requirements

WordPress sites need reliable background work: publishing future‑dated posts, checking for core/plugin/theme updates, sending queued emails, and cleaning temporary data. WP‑Cron satisfies this by storing scheduled events in the cron option (a serialized array in the wp_options table) and executing the hooks whenever wp-cron.php runs.

Smallest Suitable Design

Keep WP‑Cron’s storage and hook model but move its execution out of the request cycle. Add one line to wp-config.php to disable the built‑in spawning, then invoke wp-cron.php from a system scheduler (cron) every few minutes, or use WP‑CLI’s wp cron event run --due-now. This requires only:

1. define('DISABLE_WP_CRON', true); in wp-config.php.
2. A system‑cron entry such as */5 * * * * www-data /usr/local/bin/php /path/to/wordpress/wp-cron.php >/dev/null 2>&1.

If you prefer WP‑CLI, replace the PHP call with wp cron event run --due-now --path=/path/to/wordpress.

Trust and Data Boundary

wp-cron.php is an HTTP(S) entry point that runs with full WordPress privileges and executes any hook a plugin has scheduled. After disabling the built‑in spawn, treat the file as a privileged script that must only be reachable by your trusted scheduler. Recommended steps:

• Deny direct web access to wp-cron.php (e.g., via nginx location ~ wp-cron.php { deny all; } or an .htaccess rule).
• If you keep the default spawning for any reason, ensure loopback requests (127.0.0.1 or ::1) are allowed through firewalls and TLS interception.

Operational Checks

Verify that the scheduler is working and that WordPress sees the events:

1. List scheduled events: wp cron event list --format=table --path=/path/to/wordpress (run as the WordPress file‑system user, e.g., www-data).
2. Run due events manually: wp cron event run --due-now --path=/path/to/wordpress and confirm the output shows processed hooks.
3. Check the scheduler’s log (e.g., /var/log/syslog or journalctl -u cron) for the cron entry’s success.
4. Watch the WordPress admin under Tools → Site Health for any “loopback request” warnings when the default spawn is disabled; these should disappear.
5. Inspect the raw cron option: wp option get cron --format=json --path=/path/to/wordpress to see timestamps and verify they advance after each scheduler run.

Failure Modes

Even with a system scheduler, be aware of these residual risks:

• Overlapping runs: If the scheduler interval is shorter than the longest WP‑Cron job, a new invocation may start while the previous one is still executing, causing duplicate work. Mitigate by ensuring the interval exceeds the worst‑case runtime or by using a lock file in the scheduler entry.
• Missed lock: WP‑Cron still uses an internal lock (WP_CRON_LOCK_TIMEOUT, default 60 s). If a job holds the lock longer than the scheduler interval, subsequent runs become no‑ops until the lock releases.
• Scheduler failure: If the system cron daemon stops, all scheduled work halts silently. Monitor the cron service with your usual host‑level alerts.
• Multisite nuance: In a multisite installation, each site has its own cron option. A single scheduler call to wp-cron.php processes the current site only; you must either loop through sites or use WP‑CLI’s wp site list --field=url to invoke wp cron event run --due-now per site.

Conditions That Would Trigger a Redesign

Consider moving beyond the simple scheduler if:

• You have a large, predictable queue (e.g., bulk email, import jobs) that benefits from a dedicated worker loop such as Action Scheduler with its own daemon.
• Your hosting environment (serverless functions, containers) makes reliable loopback or system cron difficult; a CLI‑driven approach triggered by the platform’s native scheduler may be preferable.
• You observe frequent overlapping runs or lock‑timeout issues despite tuning the interval; a dedicated queue system can serialize work more predictably.

Practical Verification on a Staging Copy

1. Copy the production site to a staging subdomain or directory.
2. Add define('DISABLE_WP_CRON', true); to wp-config.php.
3. Create a test scheduler entry: */1 * * * * www-data /usr/local/bin/php /path/to/staging/wp-cron.php >/dev/null 2>&1 (runs every minute).
4. Schedule a post to publish one minute in the future via the WordPress editor.
5. Wait two minutes, then check the post’s status. If it published, the scheduler is working.
6. Run wp cron event list --path=/path/to/staging before and after manually invoking wp cron event run --due-now --path=/path/to/staging to confirm events are cleared.
7. Review Tools → Site Health for any cron‑related notices; they should be absent.

Limitations and How to Check Results

The scheduler approach does not eliminate WordPress’s internal lock mechanism; long‑running tasks will still block subsequent runs until the lock expires. To verify that a task is not being blocked:

• Measure the typical runtime of your heaviest WP‑Cron hook (e.g., a backup script) using time wp cron event run --due-now --hook=your_hook --path=/path/to/wordpress.
• Ensure the scheduler interval is set to at least that measured runtime plus a safety margin (e.g., 5 minutes).
• If you still see missed executions, increase the interval or implement an external lock (e.g., flock) around the scheduler call.

Rollback (Re‑Enabling Default WP‑Cron)

Because disabling WP‑Cron changes site state, you can revert by:

1. Removing or commenting out the define('DISABLE_WP_CRON', true); line in wp-config.php.
2. Deleting the system‑cron entry you added.
3. If you denied web access to wp-cron.php, restore the previous web‑server rule to allow loopback requests.
4. Verify that the Site Health screen now shows the loopback test as “good” and that scheduled events resume on page traffic.