Setup that assumes nothing, troubleshooting that matches the errors.
Full reference documentation ships with the plugin. What's here now is the part that's already stable: how production cron should be configured, and the five ways WordPress cron actually breaks.
The two-line change that outranks any plugin.
On a production site, don't let visitor traffic trigger scheduled tasks at all. Disable WP-Cron and run it from a real system crontab:
# wp-config.php define( 'DISABLE_WP_CRON', true );
# crontab — every 5 minutes */5 * * * * curl -s https://example.com/wp-cron.php > /dev/null 2>&1
DISABLE_WP_CRON without
adding the crontab. Scheduled posts stop publishing, order emails stop
sending, and nothing errors anywhere. SwiftQueue detects this case by
evidence — it records whether anything external has actually hit
wp-cron.php — and raises a critical Site Health warning when the crontab
is missing, instead of trusting a checkbox.
SwiftQueue's dashboard generates these commands for your exact site URL, with per-host guidance for Kinsta, WP Engine, Pantheon, Cloudways, SiteGround and others.
The five ways cron breaks.
These headings match the plugin's own diagnostic messages, so what Site Health tells you is searchable here verbatim.
1 — Loopback requests blocked
The site can't make an HTTP request to itself: host policy, a WAF answering with 403 before PHP runs, DNS that can't resolve its own hostname, or a TLS failure on staging. SwiftQueue classifies which one and says so — each has a different fix, and only one of them means "use a crontab instead".
2 — Action Scheduler table bloat
Busy WooCommerce stores accumulate hundreds of thousands of completed rows. SwiftQueue reports the bloat and can shorten Action Scheduler's own retention period — it never runs DELETE against another plugin's table itself.
3 — Stale concurrency locks
A third-party task fatals or runs out of memory mid-cron and the lock never releases. SwiftQueue registers a shutdown-function recovery that survives fatals, plus a stale-lock threshold as the backstop.
4 — Page caches intercepting wp-cron.php
A proxy serves cron requests from cache and no PHP ever runs. Dispatches send no-cache headers, and the docs include copy-paste exclusion rules for WP Rocket, LiteSpeed, W3TC, Nginx, Varnish and Cloudflare.
5 — DISABLE_WP_CRON without a crontab
The silent one. See production setup above — detection is by observed evidence, not self-report.
Known limitation — core's cron storage
WordPress keeps every scheduled event in a single option with no locking; a long cron run can overwrite events scheduled meanwhile. No plugin fully fixes this. SwiftQueue avoids adding writes to that option on ordinary requests, and documents the residual risk instead of hiding it.