WordPress uses WP-Cron to check scheduled events during page requests. This traffic-driven design is convenient for small sites, but a low-traffic site may run scheduled tasks late, while a busy site may trigger repeated checks. For production workloads, a real system scheduler can provide more predictable execution.
Understand the default behavior
WP-Cron is not a continuously running daemon. WordPress checks due events when a request loads the site and attempts to spawn the cron runner. If requests are infrequent, a scheduled post or cleanup task may run late. If requests are frequent, overlapping executions and plugin-heavy jobs can increase load.
Use a real scheduler
After verifying that the site can execute cron through WP-CLI or a protected HTTP endpoint, disable page-load cron with DISABLE_WP_CRON in wp-config.php. Then schedule a system cron entry to invoke WP-Cron at a predictable interval. The exact command should use the correct site path, PHP binary and WordPress user.
*/5 * * * * cd /var/www/site && /usr/local/bin/wp cron event run --due-now --quietTest the command manually first and check its exit status. Do not run it as root if the WordPress files belong to a dedicated site user.
Prevent overlapping jobs
Long-running imports, backups and email batches can overlap if a new run starts before the previous one finishes. Use a lock or job-specific mutex, make tasks idempotent and process work in bounded batches. A failed job should be safe to retry.
Monitor scheduled events
Inspect scheduled hooks, last run times, errors and queue length. Alert on critical jobs that have not completed within their expected window. Plugin updates can add, remove or rename hooks, so recheck schedules after major upgrades.
Operational checklist
- Run WP-Cron from a system scheduler on production.
- Use the correct PHP binary and site account.
- Check scheduled events after plugin updates.
- Make custom jobs idempotent and lock long tasks.
- Monitor missed events and execution failures.
Reliable scheduling improves publishing, backups and maintenance. See WordPress plugin failure recovery and wp-config.php security.
Design and prerequisites
Inventory the scheduled hooks that matter to the business. Publishing, email delivery, subscription renewal, cleanup, backup and import jobs may have different acceptable delays. Use WP-CLI to inspect due events and identify which plugin or theme registered each hook. A plugin update may rename or remove a hook, leaving stale scheduled entries or silently changing behavior. Keep a short register of critical jobs, their expected frequency, owner and failure impact.
Configuration strategy
Run the scheduler as the same Unix account that owns the WordPress files. Use the intended PHP binary and site path, and test the exact command manually before adding it to crontab or a systemd timer. Avoid running WordPress cron as root because files created by scheduled jobs may become incorrectly owned. Keep output available for diagnosis and alert on repeated non-zero exit codes rather than discarding every error.
Security and compatibility
Prevent overlapping executions for long-running tasks. A large import or backup may exceed the scheduler interval and start again before the first run completes. Use a lock with a clear expiry strategy, process records in bounded batches and make operations idempotent. If a process crashes, the lock should not remain forever. For important jobs, record a run ID, start time, completion state and last successful checkpoint.
Testing and validation
Use durable queues for work that should survive a web request or PHP process restart. WP-Cron can trigger a queue runner, but it should not be expected to provide durable job storage by itself. For email campaigns, large imports and media processing, use a queue system with retry limits and dead-letter handling. Make sure retries do not send duplicate emails or apply the same financial change twice.
Monitoring and diagnosis
Monitor lateness as well as failures. A scheduled task that runs successfully two hours late may still violate a business requirement. Track due time, actual start, duration, last success and number of pending events. Alert on critical hooks that exceed their allowed delay. Compare scheduler health with traffic levels and server resource pressure to identify whether jobs are delayed by low traffic, PHP saturation or a stuck worker.
Operations and maintenance
Test the setup after WordPress core, PHP, plugin and hosting changes. Confirm that DISABLE_WP_CRON is set only when a real scheduler is active, and verify that the scheduler reaches the correct site in multisite environments. Keep a rollback path to restore page-load cron temporarily if the system scheduler fails, but monitor the change so two schedulers do not create overlapping work. Document how to pause and safely resume critical jobs.
Operational handover and review
Before handing this implementation to an operations team, document the configuration owner, supported versions, dependency map and escalation path. Include the commands or dashboard views needed to verify normal operation, along with expected values and known limitations. Store configuration in version control, review changes through the normal deployment process and keep a tested rollback procedure. Schedule periodic reviews because upstream components, security requirements and workload patterns change. A short runbook should explain how to identify a failed component, what evidence to collect, which actions are safe to retry and when to escalate. Test that runbook during a maintenance exercise rather than waiting for an outage. Finally, measure the result against a baseline: reliability improvements should be visible in error rates, latency, resource consumption, recovery time or reduced manual work. This makes the implementation maintainable after the original developer has moved to another project.
Change management and production verification
Create a controlled change record for every production adjustment. Record the current value, intended value, reason, approver and expected impact before changing the live configuration. Use a staging environment or a representative test fixture to verify behavior, and compare the result against a known baseline. Keep rollback instructions beside the change record, not in an engineer’s private notes. If the change affects a shared service, coordinate the maintenance window with its consumers and define how they will report regressions.
Service-level observability
Build operational dashboards around outcomes rather than configuration alone. Track the service-level indicators that show whether the system is working: request success, latency, queue delay, resource pressure, error counts and recovery time. Add component-specific metrics where they help explain a failure, but avoid collecting high-cardinality labels that make monitoring expensive or unstable. Define alert thresholds with an owner and a response action. An alert that has no documented next step will eventually be ignored.
Failure testing and recovery
Test failure modes before declaring the work complete. Simulate a dependency outage, an invalid input, a restart during active work and a resource limit being reached. Confirm that the system fails safely, preserves recoverable state and produces useful logs. Verify that retries are bounded and that repeating an operation does not create duplicate side effects. Capture the observed behavior in a runbook so the next operator can distinguish a transient issue from a configuration defect.
Ongoing review
Review the design after the first production cycle. Compare expected and actual resource use, support incidents, maintenance effort and user impact. Remove temporary exceptions that are no longer required, update version pins deliberately and check upstream release notes before upgrades. Re-run the original validation suite after a dependency or runtime change. A technical implementation should remain understandable to a new engineer, so document trade-offs, known limitations and the reasons behind non-obvious settings.
Apply this review specifically to WordPress WP-Cron at Scale: Reliable Scheduled Jobs on Busy Sites: confirm the supported runtime and component versions, validate the behavior with a representative workload, and retain evidence from the test. Do not treat a successful configuration reload as proof that the user-facing workflow is healthy. Verify the end-to-end result from the same network path and identity used by the production application.
