A scheduled WooCommerce sale that starts late, a backup that never runs, or a queue of unsent emails usually points to the same underlying issue: WordPress did not receive a visit when it needed one. To set WordPress cron jobs reliably, move critical scheduled work away from visitor traffic and onto a real server schedule.<\/p>\n
WordPress includes its own scheduler, known as WP-Cron. It is useful, widely compatible, and sufficient for many low-traffic sites. But it is not a true operating-system cron service. Understanding that distinction helps prevent missed tasks, unnecessary server load, and confusing plugin behavior.<\/p>\n
WP-Cron checks for due events when someone loads a WordPress page. If an event is due, WordPress attempts to start it in the background. This design means a busy site may run scheduled tasks slightly late, while a quiet site may not run them for hours or days.<\/p>\n
Scheduled events can include publishing future posts, clearing cached data, processing WooCommerce actions, sending emails, renewing subscriptions, creating backups, synchronizing inventory, or running security and maintenance tasks. Many plugins depend on the same scheduling system, so a cron issue rarely affects only one feature.<\/p>\n
There is a second problem on high-traffic sites. If several requests arrive when a task is due, more than one request may try to initiate WP-Cron. WordPress has protections against this, but repeated cron checks can still add avoidable PHP and database work. On a store or membership site, that work competes with customer requests.<\/p>\n
A server cron job solves both issues. The server calls WordPress on a known schedule, whether or not visitors are browsing the site. WordPress remains responsible for the events themselves, but the trigger becomes predictable.<\/p>\n
Start by identifying what is actually failing. A task that never completes is not always a scheduling problem. It may be blocked by a plugin conflict, an exhausted PHP memory limit, a mail delivery problem, an external API timeout, or a slow database query.<\/p>\n
Use a cron inspection tool or your host’s WordPress management panel to review scheduled events. Look for events that are overdue, recurring tasks with unusual intervals, or a large backlog of one-time jobs. WooCommerce sites should also review their background action queue, because pending or failed actions can reveal an issue before customers notice it.<\/p>\n
Check whether your host has already configured a real cron trigger. Managed WordPress hosting sometimes handles this automatically. Adding a second trigger is not necessarily harmful, but it can create duplicate work or make troubleshooting harder. The correct setup depends on the hosting environment and the workload.<\/p>\n
Back up the site and record the existing configuration before editing `wp-config.php` or adding a server task. These are small changes, but they affect site-wide operations.<\/p>\n
The standard approach has two parts: disable WordPress’s visitor-triggered cron behavior, then create a server task that calls the scheduler at a fixed interval.<\/p>\n
Add the following line to `wp-config.php`, above the line that says `That’s all, stop editing!`:<\/p>\n
“`php define(‘DISABLE_WP_CRON’, true); “`<\/p>\n
This does not disable scheduled events. It only prevents WordPress from trying to initiate them during ordinary page loads. Your server cron job will take over that responsibility.<\/p>\n
Do not add this setting until the server task is ready. If visitor-triggered WP-Cron is disabled without a replacement, scheduled jobs will stop running.<\/p>\n
Most VPS and control-panel hosting accounts provide a Cron Jobs section. A common configuration runs every five minutes:<\/p>\n
“`text \/5 <\/em> <\/em> * “`<\/p>\n The command should trigger WordPress’s cron endpoint. On servers with `curl`, a typical command is:<\/p>\n “`bash curl -s https:\/\/example.com\/wp-cron.php?doing_wp_cron >\/dev\/null 2>&1 “`<\/p>\n Replace `example.com` with your actual domain. The output redirection prevents the server from sending an email every time the task runs.<\/p>\n If your server supports WP-CLI, it is often the cleaner option because it runs WordPress cron directly from the command line:<\/p>\n “`bash cd \/path\/to\/wordpress && wp cron event run –due-now –quiet “`<\/p>\n WP-CLI avoids an HTTP request and may be more dependable when a site uses strict firewall rules, maintenance mode, or unusual authentication settings. However, it requires correct server access, the right PHP version, and a user account that can read the WordPress files. On shared hosting, the HTTP method is usually easier to configure.<\/p>\n Use only one method for the same site unless your host specifically instructs otherwise. Running both an HTTP trigger and a WP-CLI trigger can create overlap without providing a useful benefit.<\/p>\n Five minutes is a practical starting point for many business sites. It is frequent enough for routine publishing, queue processing, and store maintenance without needlessly waking WordPress every minute.<\/p>\n Some tasks require a shorter interval. A busy WooCommerce store may process orders, stock updates, subscriptions, and payment-related actions more effectively with a one-minute schedule. That does not mean every site should run cron every minute. On limited hosting, frequent requests can increase CPU use and expose slow tasks that were previously hidden.<\/p>\n Less time-sensitive sites may use 10 or 15 minutes. A scheduled blog post will not suffer from a few minutes of delay, while an abandoned-cart email or subscription renewal may have stricter timing requirements. Set the interval according to the most time-sensitive legitimate task, then monitor server resources and job completion.<\/p>\n Also consider task duration. If a cron run can take longer than its interval, overlapping processes may occur. For example, a backup job that needs eight minutes should not be launched every five minutes without a locking mechanism or plugin support for preventing overlap. Increasing the interval, splitting large jobs into batches, or moving heavy backups to an off-site service is often the safer choice.<\/p>\n After creating the task, confirm that the cron endpoint is reachable. A browser request to `wp-cron.php` may return a blank page, which is normal. The meaningful result is whether due events are processed and whether the server reports a successful request.<\/p>\n Next, schedule a simple near-term test, such as a future post, then verify that it publishes at the expected time. Check the site timezone in WordPress settings before judging the result. Server time, UTC, and the WordPress timezone can differ, especially after daylight saving time changes.<\/p>\n For WooCommerce, watch pending actions after the change. A healthy queue should process regularly rather than grow continuously. Check error logs as well. Errors involving loopback requests, timeouts, PHP fatal errors, or permission problems can prevent the trigger from completing.<\/p>\n If you use a security service, basic authentication, IP restrictions, or a web application firewall, the server’s request to `wp-cron.php` may be blocked. Allow the request safely rather than disabling security controls broadly. In some environments, WP-CLI is preferable precisely because it does not rely on an external HTTP loopback.<\/p>\n The most common mistake is disabling WP-Cron but entering an invalid cron command. Check the domain, file path, command availability, and cron syntax carefully. A second frequent issue is using a command that works in an interactive SSH session but fails under cron because cron has a limited environment and different PATH settings. Use full command paths when necessary.<\/p>\n Another issue is caching or security software interfering with `wp-cron.php`. This endpoint should not be cached. If a firewall rate-limits or challenges the request, WordPress may never receive the trigger. Review logs before changing multiple plugins at once.<\/p>\n Finally, avoid treating cron as a replacement for a full job queue system when the workload is large. Sending thousands of emails, importing a large catalog, or generating extensive reports may exceed what a single WordPress request can safely do. Those jobs need batching, reliable retry handling, and possibly server-level workers or specialized infrastructure.<\/p>\n Reliable scheduling is a small operational improvement with a noticeable effect: stores process background work on time, scheduled content appears when planned, and page requests spend less effort starting maintenance tasks. Configure the trigger, verify the jobs it supports, and revisit the interval as your site’s workload changes.<\/p>\n","protected":false},"excerpt":{"rendered":" Learn how to set WordPress cron jobs with reliable server scheduling, correct timing, safe testing, and practical fixes for missed tasks and slow sites.<\/p>\n","protected":false},"author":0,"featured_media":46513,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_lock_modified_date":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-46512","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-solutions"],"_links":{"self":[{"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/posts\/46512","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/comments?post=46512"}],"version-history":[{"count":0,"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/posts\/46512\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/media\/46513"}],"wp:attachment":[{"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/media?parent=46512"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/categories?post=46512"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.s-sols.com\/api\/wp\/v2\/tags?post=46512"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Choose an interval that matches the work<\/h2>\n
Test the configuration instead of assuming it works<\/h2>\n
Common mistakes that cause missed jobs<\/h2>\n