wp-plugin-cron

WordPress plugin: cron & background jobs

Scheduled work — daily cleanup, periodic API sync, deferred email send, retry on failed webhook delivery — is a normal part of plugin life. WordPress ships its own cron primitive (wp_schedule_event), and the WooCommerce-bundled Action Scheduler library extends the model into a proper queue. Picking between them and using the chosen one correctly is what this skill covers.

When to use this skill

Trigger when ANY of the following is true:

• Scheduling a periodic task (daily option cleanup, hourly token refresh, weekly digest email).
• Deferring work off the request thread (e.g. send email after the form submission returns).
• Debugging "my cron event was registered but never fires" or "fires multiple times" or "fires hours late".
• Deciding between native WP cron and Action Scheduler for a non-trivial background workload.
• Reviewing a plugin's activation / deactivation hooks for cron schedule + clear correctness.

Mental model — WP cron is pseudo-cron, not real cron

WordPress cron does NOT run on a system schedule. There is no cron daemon waking WP up. Instead:

1. Page request comes in.
2. On init, WordPress calls wp_cron() (wp-includes/default-filters.php).
3. Since WP 6.9, wp_cron() registers _wp_cron() on shutdown for normal requests, so the cron spawn does not hurt TTFB as much. With ALTERNATE_WP_CRON, it still uses wp_loaded.
4. _wp_cron() checks for due events and makes a non-blocking loopback request to /wp-cron.php, which actually runs the due events.

In WordPress 7.1, the cron spawn passes its resolved cron URL as the second argument to https_local_ssl_verify. Existing one-argument callbacks continue to work, while a filter that needs host-specific local TLS policy can register for two arguments. Keep verification exceptions exact and development/host specific; do not disable TLS verification globally for cron.

Implications:

• No traffic = no cron. A site with 5 visitors/day fires cron events 5 times/day, max. A "daily" event on a low-traffic site might run every 3 days.
• Late firing is normal. An "hourly" event scheduled at noon may fire at 12:47 if that's when the next visitor lands.
• Concurrent visitors can race. WP has internal locking but it's best-effort; on a busy site, two requests may both attempt to spawn the same event before the lock takes effect.
• Long-running events block the loopback. If your daily_cleanup callback runs 90 seconds, the wp-cron.php request takes 90 seconds. Other due events in that batch wait.