WordPress normally runs scheduled tasks through WP-Cron, a traffic-driven system that checks for due events when someone visits the site. That is convenient, but low-traffic sites may run jobs late while busy sites can trigger unnecessary checks on many requests. An external web cron job gives the schedule a predictable clock.
The safe approach is to let WordPress keep its event queue while a trusted HTTPS request wakes it at a fixed interval. This guide explains how to make that change without exposing sensitive access or creating overlapping executions.
Understand what WP-Cron actually does
WP-Cron stores scheduled events and runs callbacks registered by WordPress core, themes, and plugins. It handles publishing, update checks, cleanup, email queues, backups, and other plugin-defined work. Replacing the trigger does not replace this event system; it only changes how WordPress is told to process due events.
Decide whether an external trigger helps
Use an external scheduler when jobs run late on quiet sites, traffic is highly variable, or you need execution history outside WordPress. If the current setup is timely and reliable, changing it may add complexity without a meaningful benefit.
Inventory scheduled events first
List the event hooks, intervals, owners, and expected runtimes. Remove abandoned plugin events and investigate callbacks that run for minutes. A predictable trigger cannot fix a slow or broken callback.
Choose a sensible interval
Five minutes is a practical starting point for many sites. Publishing or queue workloads may need one minute, while housekeeping can run less often. Use cron expression examples to build the schedule and avoid polling more frequently than the shortest useful event interval.
Disable traffic-driven spawning carefully
After the external request is ready, set DISABLE_WP_CRON to true in the WordPress configuration. Do not disable WP-Cron first: due events would stop until the external scheduler is working. Make the change during a period when you can verify several consecutive runs.
Call the real cron endpoint over HTTPS
Schedule a request to wp-cron.php?doing_wp_cron on the canonical HTTPS domain. Confirm that redirects do not send the request through a login page, security challenge, or alternate hostname. The scheduler needs a normal successful response.
Protect the request path
The standard endpoint does not accept arbitrary commands, but repeated public requests can still waste resources. Use rate limits, a narrowly scoped firewall rule when practical, or a protected wrapper endpoint. Apply the principles in securing web cron endpoints without blocking legitimate site traffic.
Avoid embedding administrator credentials
WP-Cron does not require an administrator password. Never put WordPress login credentials, hosting credentials, or database secrets in the cron URL. If a wrapper uses a secret, give it one narrow purpose and rotate it independently.
Set timeouts intentionally
The HTTP response may finish before all spawned work completes. Use a timeout long enough to establish the request, but do not let a slow connection hang indefinitely. Monitor the actual WordPress events separately from the transport response.
Prevent overlapping heavy callbacks
WordPress uses internal locks, but long plugin jobs can still overlap or contend with manually triggered work. Give heavy import, backup, or email routines their own locks. Review overlap prevention patterns when callbacks modify shared records.
Make plugin jobs idempotent
A callback should tolerate a retry without duplicating orders, messages, or records. Store durable progress markers and unique operation identifiers. The safeguards in retry strategies for cron jobs are especially important for commerce and notification plugins.
Check caching and security layers
Exclude the cron endpoint from page caches. Confirm that a CDN, web application firewall, maintenance plugin, or bot filter does not replace the response with cached HTML or a challenge. Allow only what is necessary rather than disabling protection site-wide.
Test scheduled publishing
Create a private test post scheduled a few minutes ahead, then confirm it becomes public at the expected time. Also test a harmless plugin event such as a cleanup or queued notification. Follow the web cron testing checklist before relying on the new trigger.
Monitor more than HTTP 200
A successful request proves only that the endpoint answered. Check overdue events, job duration, queue depth, PHP errors, and missed schedules inside WordPress. Combine those signals with external cron monitoring.
Plan failure and recovery
Document how to re-enable traffic-driven WP-Cron if the external scheduler is unavailable. Alert after consecutive failures, not one transient timeout. When service returns, let WordPress process the backlog in controlled batches instead of sending many manual requests.
Migration checklist
- Inventory existing hooks and remove abandoned events.
- Create and verify the external HTTPS schedule first.
- Disable traffic spawning only after successful test runs.
- Keep credentials out of the URL and rate-limit safely.
- Test publishing, plugin jobs, retries, and recovery.
- Monitor overdue events as well as HTTP responses.
Final takeaway
An external web cron makes WordPress scheduling predictable without replacing the WordPress event system. Preserve the native queue, use a measured interval, protect the trigger, and monitor the callbacks that matter. The result is more reliable publishing and background work with less dependence on visitor traffic.