Summary
The Cron overview page (cron/index.md) currently covers only "What is WP-Cron" and "Why use WP-Cron" in a few short paragraphs. Several topics that developers commonly need when working with WP-Cron are not addressed anywhere in the Cron chapter.
Gaps identified
1. Understanding the limitations
No page in the Cron chapter discusses:
- Timing accuracy — WP-Cron depends on page loads, so tasks on low-traffic sites can be delayed significantly. This is mentioned in one sentence on the overview but not explained in practical terms.
- Performance impact on high-traffic sites — every page load triggers a cron check. Resource-intensive callbacks can affect response times. No guidance on keeping callbacks lightweight.
- Concurrent execution — if two visitors load a page simultaneously and a task is due, it may execute twice. No mention of this race condition or common mitigation patterns (e.g., transient-based locking).
2. WP-Cron on managed hosting
Many managed WordPress hosts (Kinsta, WP Engine, Pressable, Cloudways, etc.) disable the default WP-Cron page-load trigger and run wp-cron.php via system cron on a fixed interval. This is not mentioned anywhere in the chapter. Developers building plugins need to know their cron callbacks should work correctly regardless of how they are triggered.
3. Troubleshooting beyond Simple Testing
The Simple Testing subpage covers WP-CLI and inspection functions, but the chapter does not address:
- Testing
wp-cron.php externally via curl to verify accessibility
- Enabling
WP_DEBUG_LOG to capture errors from cron callbacks
- A quick-reference table of common symptoms (task never runs, runs late, runs multiple times, disappears after update) with likely causes and solutions
4. Alternatives to WP-Cron
For plugins that need reliable scheduling, retries, chaining, or batch processing, Action Scheduler (maintained by Automattic, used by WooCommerce) is the standard solution. It is not mentioned anywhere in the handbook.
Proposal
I am happy to submit a PR with content for these sections. Before writing, I would like the docs team's input on where this content best fits:
- Option A: Add new sections to the existing overview page (
cron/index.md)
- Option B: Create a new subpage (e.g.,
cron/limitations-and-best-practices/index.md)
- Option C: Distribute across existing subpages where relevant
I have draft content ready and can adapt it to whichever structure the team prefers.
References
Summary
The Cron overview page (
cron/index.md) currently covers only "What is WP-Cron" and "Why use WP-Cron" in a few short paragraphs. Several topics that developers commonly need when working with WP-Cron are not addressed anywhere in the Cron chapter.Gaps identified
1. Understanding the limitations
No page in the Cron chapter discusses:
2. WP-Cron on managed hosting
Many managed WordPress hosts (Kinsta, WP Engine, Pressable, Cloudways, etc.) disable the default WP-Cron page-load trigger and run
wp-cron.phpvia system cron on a fixed interval. This is not mentioned anywhere in the chapter. Developers building plugins need to know their cron callbacks should work correctly regardless of how they are triggered.3. Troubleshooting beyond Simple Testing
The Simple Testing subpage covers WP-CLI and inspection functions, but the chapter does not address:
wp-cron.phpexternally viacurlto verify accessibilityWP_DEBUG_LOGto capture errors from cron callbacks4. Alternatives to WP-Cron
For plugins that need reliable scheduling, retries, chaining, or batch processing, Action Scheduler (maintained by Automattic, used by WooCommerce) is the standard solution. It is not mentioned anywhere in the handbook.
Proposal
I am happy to submit a PR with content for these sections. Before writing, I would like the docs team's input on where this content best fits:
cron/index.md)cron/limitations-and-best-practices/index.md)I have draft content ready and can adapt it to whichever structure the team prefers.
References
DISABLE_WP_CRONbut not the broader context of managed hosting environments