WP-Cron vs Server Cron: Fix Delayed WordPress Tasks

WordPress & Web Development · Scheduled tasks · Practical guide

Use the default WP-Cron trigger when scheduled tasks run reliably enough for your site. Consider a server cron when traffic-dependent triggering causes unacceptable delays or your host recommends a managed schedule. Keep WordPress’s event system: change how due work is triggered, then verify that the work actually completes.

A missed scheduled post is a useful symptom, but it does not identify the cause. The trigger might be absent, a request might fail, or a plugin callback might start and then encounter an error. Adding a more frequent trigger addresses only part of that chain.

This guide explains the decision, checks to make first, and a controlled changeover. Documentation checked on 25 October 2026. Commands are examples for an administrator to adapt; no particular hosting account, PHP path, or cron interval is assumed.

WP-Cron and server cron operate at different layers

WordPress’s Cron handbook describes WP-Cron as the system used for tasks such as scheduled publishing and update checks. Its normal trigger depends on page loads reaching WordPress; it is not a continuously running clock service. A quiet site can therefore process due tasks later than their scheduled time.

A server cron is the operating system’s scheduled launcher. It can invoke WordPress periodically without waiting for a visitor. WordPress still needs to load successfully, identify due events, and run their callbacks.

Imagine a hypothetical brochure site with no requests reaching WordPress overnight. A post due at 07:00 may wait for a later request under the default trigger. A periodic server trigger reduces that dependence, but its interval and the task’s execution time still matter.

Diagnose the delay before changing the trigger

Start by recording the expected task, its scheduled time, the observed result, and the timezone used in each screen or log. “It ran late” becomes more useful when you can identify which part happened late.

Open Tools → Site Health and review relevant warnings. WordPress’s Site Health documentation explains that loopback requests support scheduled events. A loopback warning is a reason to investigate the request path, not proof that a server cron will fix every affected operation.

• Check whether the host already provides a WordPress scheduler.
• Inspect existing account cron entries before adding another.
• Check whether DISABLE_WP_CRON is already defined.
• Collect relevant PHP errors and plugin task logs.
• Confirm the task is still registered and belongs to an active feature.

If a loopback reports an HTTP error, give the host the status, timestamp, and affected URL. Investigate the specific authentication, security, routing, or server error shown by the evidence. Avoid broad security exceptions merely to make a warning disappear.

Distinguish the symptom from a caching issue too: an event may complete while a visitor still sees an older page. Check the underlying post status or plugin result before deciding that the scheduler failed.

Inspect the event schedule with WP-CLI

If your host provides WP-CLI, run commands as the website’s owning account, from the correct WordPress installation. The event-list command lists scheduled hooks and their next run times. Its default output includes next_run_gmt, so compare times carefully.

wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence

This inspection does not ask WP-CLI to run the listed hooks. Save a before-and-after record for the events relevant to your problem. If an unfamiliar hook appears, identify its owning plugin before changing or deleting it.

Understand what the spawning test checks

The WP-CLI cron test checks the spawning system and attempts an HTTP spawn. It can therefore trigger due work; use it deliberately rather than treating it as a purely passive check.

wp cron test

The command reports an error when DISABLE_WP_CRON is true. After an intentional server-cron setup, that result alone does not establish that the replacement launcher is broken. Inspect the replacement’s execution and task outcomes instead. A successful spawn likewise does not prove every callback completed.

Choose a trigger your host can support

First ask whether the host already operates a scheduler for the site. If so, get its interval, scope, and troubleshooting process before adding a competing entry.

WordPress’s system task scheduler guide documents calling wp-cron.php through a web request. Use the correct HTTPS address and verify that the request reaches the WordPress cron endpoint rather than a login page, challenge, or unrelated redirect.

Where WP-CLI is available, its event-run command provides another way to execute due hooks:

wp cron event run --due-now

Do not use --all as a substitute: that option runs all hooks, including ones that are not yet due. Before a manual run, consider what is pending, such as publication, notifications, or plugin operations.

For an unattended command, have the host confirm the absolute executable path, WordPress path, account identity, and PHP environment. An interactive command working in your shell does not establish that cron has the same environment.

Change over only after the replacement runs

Prepare a recoverable configuration copy and a rollback plan before editing the live site. Use a safe test environment for configuration checks, following our WordPress staging-to-live checklist. Keep staging mail and other external effects controlled.

In cPanel, the Cron Jobs interface separates the timing fields from the command. Use the host-confirmed absolute paths. cPanel also warns against intervals so short that earlier jobs are still running when later ones start.

1. Record the current trigger and configuration.
2. Add one approved replacement launcher at the intended interval.
3. Observe its unattended execution and the result of a known due task.
4. Once it works, disable the normal page-load spawning as appropriate for the host’s setup.
5. Watch subsequent intervals and document how to restore the previous configuration.

The WordPress system-scheduler guide specifies this configuration line:

define( 'DISABLE_WP_CRON', true );

Edit an existing definition rather than adding a duplicate. This disables automatic page-load triggering; it does not delete scheduled events. Do not leave it enabled with no working replacement.

During setup, retain a practical way to see errors. Discarding all output immediately makes an incorrect path or failed bootstrap harder to discover. Keep logs private and avoid recording unnecessary sensitive data.

Verify task outcomes, including plugin-specific queues

Use three separate checks: the launcher ran, due work was processed, and the intended result exists. For a publishing task, inspect the post status and public availability. For a backup, inspect the backup product’s completion record and the expected artifact.

Action Scheduler’s documentation describes a separate background job queue with action logs, a WP-Cron hook, and asynchronous processing. If a plugin uses it, inspect that queue’s pending and failed actions as well. A clean WP-Cron event list alone does not establish that its entire queue is healthy.

For command-level failures, cPanel’s troubleshooting guidance recommends running the exact command as the account user and correcting returned errors. Preserve the failing command and context so support can reproduce the problem.

Keep an operating record and review recurring failures

Record the site’s owner, launcher method, account, interval, executable and installation paths, output location, and rollback procedure. Update the record after a migration or PHP change.

WordPress’s event-scheduling guidance warns that repeatedly registering an event can create duplicates and that unused tasks need cleanup. If you see repeated unfamiliar events, ask the plugin maintainer to confirm their purpose before bulk deletion.

Define an alert around useful work: for example, investigate when an expected daily backup has no successful completion record. Scheduler activity by itself is a weak substitute for that result. Set the threshold around your own operating requirements.

If the new trigger fails, restore the previously recorded configuration while investigating. Avoid leaving both methods disabled. Review after several representative cycles, including a quiet traffic period and the site’s heavier scheduled workload.

Frequently asked questions