A scheduled WooCommerce sale that starts late, a backup that never runs, or a batch of transactional emails stuck in a queue often has the same cause: WordPress is waiting for a visitor before it processes background work. Learning how to configure WordPress cron with a real server scheduler gives those tasks a predictable schedule and removes unnecessary work from normal page requests.
For a low-traffic site, WordPress’s default cron behavior may be sufficient. For a business site, store, membership platform, or content operation, it is usually better to take control. The change is small, but it affects tasks that customers and administrators notice.
What WordPress Cron Actually Does#
WordPress does not use the operating system’s cron service by default. Instead, it uses WP-Cron, a virtual scheduler. When someone loads a page, WordPress checks whether scheduled jobs are due. If they are, it starts `wp-cron.php` and processes them.
This approach makes installation simple because it works even on basic hosting. It also creates two practical problems. A site with little traffic may not process a due job for hours. A site with heavy traffic may repeatedly check for scheduled work, adding avoidable PHP and database activity to page loads.
WP-Cron can handle more than core WordPress tasks. Plugins use it for actions such as order cleanup, scheduled promotions, cache preloading, security scans, subscription renewals, report generation, email queues, and automated imports. That is why cron configuration deserves attention before a site becomes slow or unreliable.
When You Should Configure WordPress Cron Externally#
An external server cron is most useful when scheduled tasks are time-sensitive or resource-intensive. WooCommerce stores, sites using backups or security scans, and installations with multiple active plugins are common examples. It is also a sensible baseline for any site hosted on a VPS or managed server where you control scheduled jobs.
There is a trade-off. External cron requires access to a hosting control panel, SSH, or server administration tools. A poorly configured job can run too often and consume resources, while a job that runs too rarely can delay scheduled work. The goal is not the fastest possible interval. It is an interval that matches the site’s operational needs.
For many business sites, every five minutes is a practical starting point. A simple brochure site may need only a 15-minute interval. Stores with active order processing, recurring payments, scheduled stock updates, or frequent email automation may need five minutes. Running jobs every minute is rarely necessary unless an application has a clear requirement for it.
Step 1: Disable WordPress’s Visitor-Triggered Cron#
Before adding a system cron job, disable the default behavior. Otherwise, WordPress may still attempt to launch cron checks during visitor requests, which defeats much of the purpose.
Open the site’s `wp-config.php` file and add the following line above the comment that says to stop editing:
“`php define(‘DISABLE_WP_CRON’, true); “`
Save the file and confirm that the site still loads normally. This setting does not remove scheduled events. It only tells WordPress not to trigger them on every page visit. Your server cron job will take over that responsibility.
Do not use `DISABLE_WP_CRON` without creating an external scheduler. If you disable the built-in trigger and do nothing else, scheduled posts, maintenance actions, backups, and plugin tasks may stop running altogether.
Step 2: Create a Server Cron Job#
The most dependable approach is to run WordPress cron through the PHP command-line interpreter. This avoids relying on an HTTP request and keeps the job within the server environment.
A typical cron command looks like this:
“`bash /5 * /usr/bin/php /home/account/public_html/wp-cron.php >/dev/null 2>&1 “`
This tells the server to run `wp-cron.php` every five minutes. The final section, `>/dev/null 2>&1`, discards normal command output and error output. That prevents your hosting account from generating unnecessary cron emails. During initial testing, you may want to remove that section temporarily so you can see errors.
You will need to adjust two paths. The PHP executable may be located at `/usr/bin/php`, `/usr/local/bin/php`, or another location chosen by your host. The WordPress path must point to the actual `wp-cron.php` file in your installation. If WordPress is installed in a subdirectory, include that directory in the path.
For example, if a site is installed in `/home/account/public_html/store`, the command becomes:
“`bash /5 * /usr/bin/php /home/account/public_html/store/wp-cron.php >/dev/null 2>&1 “`
Most hosting control panels provide a Cron Jobs screen where you select the interval and enter the command. On a VPS, add the command using the crontab for the site user rather than the root account whenever possible. This helps keep file permissions and environment settings consistent with the WordPress installation.
Using WP-CLI Instead#
If WP-CLI is installed and supported by your host, it provides a clean alternative:
“`bash /5 * cd /home/account/public_html && /usr/local/bin/wp cron event run –due-now –quiet “`
This command runs only events that are due. It is particularly useful for administrators who already manage WordPress through the command line. However, WP-CLI is not available on every shared hosting plan, and its path can vary. The direct PHP method is generally easier to deploy and troubleshoot.
Use one method, not both. Running `wp-cron.php` and a WP-CLI cron command at the same interval creates duplicate checks and makes troubleshooting less clear.
Step 3: Choose an Interval That Fits the Workload#
Cron frequency should reflect business requirements, not habit. A five-minute schedule is appropriate when delays affect customers, sales, or operations. Examples include WooCommerce order actions, membership access changes, recurring billing, and time-limited discounts.
A 10- or 15-minute interval is often enough for scheduled posts, noncritical imports, routine cleanup, and moderate email processing. If backup or optimization tasks create high CPU usage, schedule them during lower-traffic hours rather than increasing cron frequency.
Avoid assuming that more frequent cron runs make a site faster. The scheduled job still has to execute plugin code, query the database, and possibly contact external services. On a limited hosting plan, a busy cron schedule can compete with real visitors for PHP workers, memory, and database capacity.
Step 4: Verify That Scheduled Events Run#
After configuring the job, test it before relying on it. Schedule a WordPress post a few minutes ahead, then confirm that it publishes at the expected time. If the site sends routine admin emails, verify that those are arriving as expected as well.
For more detailed inspection, use a cron management plugin temporarily or WP-CLI commands to review scheduled events. Look for overdue actions, recurring events with unusually long runtimes, or tasks that fail repeatedly. A cron scheduler can trigger a task, but it cannot fix errors inside a plugin, API connection, mail configuration, or custom code.
Server logs are also useful. If the cron command fails, common causes include an incorrect PHP path, an incorrect WordPress file path, PHP version mismatch, insufficient permissions, or hosting restrictions on scheduled tasks. Test the same command through SSH when possible. A command that works manually but fails in cron may be missing a full executable path or required environment setting.
Common Configuration Mistakes#
The first mistake is disabling WP-Cron and forgetting to add a replacement job. The second is creating multiple cron jobs for the same site, often after changing hosting providers or testing different methods. Review existing scheduled jobs before adding a new one.
Another issue is choosing an interval that is too aggressive for the server. If cron runs every minute but a large backup, import, or report job takes several minutes, tasks can overlap or repeatedly contend for resources. WordPress includes locking behavior to reduce duplicate processing, but long-running jobs still deserve investigation.
Finally, do not treat cron as a substitute for performance work. If scheduled tasks are consistently slow, examine the responsible plugin, database size, object caching, external API response times, and available PHP memory. A properly configured scheduler makes timing reliable. It does not make inefficient code inexpensive to run.
A reliable cron setup is one of those quiet improvements that prevents visible business problems before they start. Set a sensible interval, verify it with real scheduled work, and revisit it whenever you add automation that customers depend on.