TL;DR: WP Engine does not disable WordPress cron by default — it is still traffic-dependent until you turn on WP Engine Alternate Cron.
- By default, WP-Cron fires on visitor page loads, just like any host.
- Enabling Alternate Cron in the User Portal sets
DISABLE_WP_CRON = trueand runs a server service that curlswp-cron.phpevery minute. - Defining
DISABLE_WP_CRONyourself only stops the trigger — it does not enable the replacement.
/ Default
Does WP Engine run WordPress cron jobs?
Yes — and by default it runs them the ordinary way. Contrary to a common assumption, WP Engine does not automatically disable WordPress cron. Out of the box, WP-Cron on a WP Engine site is traffic-dependent: WordPress checks for due scheduled events on visitor page loads and runs whatever is due. Per WP Engine's own documentation, "simply disabling wp cron within the environment's config file will not enable WP Engine alternate cron on its own."
That default is fine for a busy site with steady traffic but unreliable for a quiet one: with no visitors, nothing triggers the cron, and scheduled tasks pile up until the next page load. That is the exact problem WP Engine's Alternate Cron exists to solve.
/ Alternate Cron
How does WP Engine Alternate Cron work?
WP Engine Alternate Cron is an opt-in, server-based service you enable from the User Portal. When you turn it on, WP Engine adds define( 'DISABLE_WP_CRON', true ) to wp-config.php for you — switching off the traffic-based trigger — and starts a platform process that, in WP Engine's words, "checks for 'due now' crons every minute by curling wp-cron.php, rather than running cron processes based on traffic flow."
The result is a predictable one-minute heartbeat that is independent of whether anyone is visiting the site. Every minute the service hits wp-cron.php, WordPress evaluates the schedule, and any due hooks fire via do_action(). If nothing is due, the request exits and waits for the next tick.
Alternate Cron checks for "due now" crons every minute by curling wp-cron.php, rather than running cron processes based on traffic flow. — WP Engine support documentation
/ Enabling
How do you enable it, and why did DISABLE_WP_CRON alone not work?
Enable Alternate Cron through the WP Engine User Portal for the environment — not by editing files. This is the point that trips people up: adding define( 'DISABLE_WP_CRON', true ) to wp-config.php by hand disables the page-load trigger but starts nothing in its place, so your events simply stop running.
PHP — this line alone leaves nothing running your cron
// Disables the traffic-based trigger… define( 'DISABLE_WP_CRON', true ); // …but WP Engine Alternate Cron is what actually curls wp-cron.php. // Enable it in the User Portal — do not just define the constant.
Once Alternate Cron is on, you can confirm the constant is set by checking Site Health, which will report that DISABLE_WP_CRON is true and that WP-Cron spawning is disabled — expected and correct on WP Engine with Alternate Cron enabled.
/ Limits
What are the limits of one-minute cron?
A one-minute tick is reliable but not instant. Every scheduled event still only fires on the next minute boundary, so a task scheduled for time() + 5 can be up to roughly a minute late. For the vast majority of WordPress work — sending queued email, expiring transients, syncing feeds — that is invisible. It matters when you need sub-minute latency or exactly-on-the-second execution, which cron of any kind is the wrong tool for.
| Concern | Default (page-load) cron | WP Engine Alternate Cron |
|---|---|---|
| Trigger | Visitor page loads | Server service, every minute |
| Runs with zero traffic | No — tasks stall | Yes — independent of visitors |
DISABLE_WP_CRON | Not set | Set to true automatically |
| Latency | Whenever the next visitor arrives | ≤ ~1 minute |
| How to enable | Default | User Portal toggle |
/ Real cron
When should you use a real system cron instead?
If you want tighter control than a one-minute curl, the general WordPress recommendation applies: disable the built-in trigger and drive wp-cron.php from a real scheduler at whatever interval you choose. On most hosts that is a server crontab entry; on WP Engine, Alternate Cron already is that server-side scheduler, so the practical move is to enable it rather than roll your own. The mechanics of hooking events, and the trade-offs of external triggers, are covered in the WP-Cron developer reference and in setting up a real cron job for WordPress.
| Need | Page-load WP-Cron | Server-driven cron (incl. Alternate Cron) |
|---|---|---|
| Fires without traffic | No | Yes, on a fixed interval |
| Predictable timing | No — depends on visitors | Yes — every minute (WP Engine) |
| Setup | None, but unreliable | One toggle in the User Portal |
/ Queues
Should you use Action Scheduler on WP Engine?
For heavy, retryable background work — bulk imports, thousands of outbound API calls, order processing — a cron heartbeat alone is not enough; you want a queue on top of it. Action Scheduler gives each job its own database row, automatic retries, and a delivery log, but it still needs a cron tick to run its queue. On WP Engine that means Alternate Cron provides the reliable minute-by-minute heartbeat, and Action Scheduler drains the queue on each pass. For the difference between a bare scheduled event and a real queue, see WordPress async background processing.