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, disabling WP-Cron in the environment's config file does 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. The warnings that follow are decoded in DISABLE_WP_CRON is set to true.
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 with wp config get DISABLE_WP_CRON, or with the WP Crontrol plugin, which shows "The DISABLE_WP_CRON constant is set to true. WP-Cron spawning is disabled." That is expected and correct on WP Engine with Alternate Cron enabled. Core Site Health does not list the constant.
/ 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 |
| Caveats | Runs inside a visitor request | Each wp-cron.php run must finish within 60 seconds (a 502 in the access log means a timeout); does not work behind basic auth or other custom password protection |
/ 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. Where you do have a crontab, the cron job generator builds the line for you.
| 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 |
Seeing it run beats reading about it. The live preview boots a throwaway WordPress with Webhook Actions already installed and demo deliveries sitting in the log — no signup, nothing left on your machine afterwards.
/ Queues
Should you use Action Scheduler on WP Engine?
For heavy 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, a status, and a per-action log with the error message when it fails. It does not retry failed actions — retries are up to your code. Its default trigger is a WP-Cron event (plus async loopback requests at the end of admin page loads), so on WP Engine 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.
