When scheduled publishing, backups, updates, or email actions fail, WordPress WP-Cron not running troubleshooting should begin with evidence. WP-Cron is WordPress’s request-triggered scheduling system. It checks for due events when someone visits the site, rather than running as a constantly active service.
That design works well for many sites. However, low-traffic websites may not receive a request at the right time. Hosting controls, caching, security plugins, time zones, and a disabled setting can also interrupt scheduled work. This guide provides a safe diagnostic path for site owners and property operators.
How WP-Cron works and why tasks get missed
WordPress stores scheduled events in its database. Examples include publishing a post, checking for updates, processing plugin queues, and running maintenance tasks. A visitor request can trigger WordPress to inspect those events and run work that has become due.
WP-Cron does not guarantee execution at the exact minute shown in the dashboard. It is closer to “run when WordPress receives a suitable request.” A quiet brochure site can therefore accumulate missed events even when the website itself appears healthy.
Some hosts or administrators define DISABLE_WP_CRON in wp-config.php. That setting stops normal request-based triggering. It usually belongs with a real operating-system cron job that calls WordPress on a controlled schedule. If both systems remain active, duplicate processing can occur.
First, identify the symptom. Is one plugin failing, or are all scheduled events late? Does the task run after a manual visit? Did the problem start after a hosting, caching, security, or configuration change? Those answers narrow the likely cause.
Start with safe WordPress WP-Cron not running troubleshooting
Before changing configuration, record the site URL, hosting account, WordPress version, affected plugin, event name, expected time, and actual result. Take a current backup that you can restore. Avoid deleting every scheduled event because some events support important maintenance tasks. This evidence is the foundation of WordPress WP-Cron not running troubleshooting.
Next, inspect the schedule with a reputable management tool or the hosting control panel. Look for these conditions:
- Past-due events: The scheduled time has passed, but the event remains pending.
- Repeated failures: The same hook appears to run and fail again.
- Missing events: The plugin no longer registers the task.
- Unusually large queues: Many events wait for processing.
- Long-running work: A task begins but hits a timeout or memory limit.
A hook is an internal name that identifies a scheduled action. It is not always obvious from the site’s visible settings. Plugin documentation or support may be needed to interpret it correctly.
Check whether a simple visit changes the event status. Use a private browser window or a controlled test page if appropriate. Do not repeatedly refresh a production site while a task may send messages, create orders, or modify records.
If the event runs after a visit, low traffic or blocked loopback requests becomes more likely. If it never runs, inspect errors, configuration, and the task’s own code path.
Check low traffic, caching, and loopback access
Low traffic is a common explanation for delayed WP-Cron events. A site with few visitors may not create the request that starts the scheduler. This does not mean the site is broken. It means the trigger does not match the site’s operating pattern.
Caching can complicate the picture. A page-cache system may serve a stored response without reaching WordPress. A security layer may challenge or block internal requests. Some hosts also restrict loopback requests, which are requests from the server back to the same site.
Review the Site Health screen for loopback or REST API warnings. Inspect web-server and security logs around the expected execution time. Compare a normal front-end request with a request made from the server, if your host provides a safe testing method.
For broader hosting limitations, compare the site’s environment with the capabilities described in this managed WordPress hosting requirements guide.
Do not disable every security rule to test this theory. Instead, identify the exact request, response code, redirect, timeout, or block reason. A 403 response may indicate access control. A timeout may point to a firewall, DNS, PHP worker, or application problem.
For background actions that depend on external services, check outbound connectivity and API credentials separately. A scheduler can start successfully while the task still fails when it calls another service.
Verify whether WP-Cron is disabled
Search the configuration for DISABLE_WP_CRON. The setting may appear in wp-config.php, an environment variable, a deployment template, or a host-managed configuration layer. Human verification matters because configuration locations differ by hosting platform.
If the value is enabled, determine whether a replacement server cron job exists. A replacement should call WordPress at a documented interval and produce a usable log or alert. Do not simply remove the setting on a live site without checking the hosting design.
Also review plugin and theme code that schedules or unschedules events. A deployment, plugin deactivation, or failed update may remove an event. If the event is missing, restoring the scheduler alone will not restore the task.
WordPress’s official REST API Handbook can help when a hosting control panel or monitoring tool uses authenticated WordPress requests. Keep that integration separate from the scheduler diagnosis, and protect any credentials it uses.
Use a server cron job for predictable schedules
Sites that need reliable timing often use a system cron job instead of relying only on visits. A server cron job is an operating-system task that runs on a defined schedule. The exact command depends on the host, PHP setup, WordPress path, and access permissions.
Common designs include a host-provided WordPress scheduler, a command-line WordPress tool, or a request to wp-cron.php. Each option has different security and resource implications. Ask the host which method they support before adding one.
Use one scheduling model deliberately. If request-based execution remains active while a server job runs, the same event may receive competing triggers. If you disable request-based execution but create no replacement, tasks will stop entirely.
After creating a server job, verify four details:
- The job runs under an account that can access the site.
- The working directory and PHP binary match the hosting environment.
- Output and errors go to a monitored log, not an ignored mailbox.
- The schedule runs often enough for the business requirement.
Do not copy a command from another server and assume it is safe. Paths, PHP versions, container boundaries, and permissions can differ. A host or administrator should confirm the final configuration.
Check time zones and scheduled task timing
WordPress has a site time zone under its general settings. The server has its own system time zone. Cron tools may display times in yet another zone. These differences can make a healthy task look late or early.
Compare the site time zone with the business’s expected operating time. Then compare the server’s clock and the scheduler’s displayed zone. Daylight-saving changes can also affect tasks that run at a local clock time.
Record times with the date, zone, and offset. “Runs at 9:00” is incomplete unless everyone agrees whether that means Eastern, UTC, or the server’s local zone. For critical workflows, test one future event and observe the actual execution.
Time-zone checks will not fix a task that fails inside its callback. They only separate timing confusion from execution failure. Continue to logs and application results after confirming the clocks.
Diagnose failed background actions
A scheduled event may fire and still fail. The callback might hit a PHP fatal error, memory limit, execution timeout, database error, API failure, or permission problem. A plugin may also reject the action because required data is missing.
Review the WordPress debug log, PHP error log, web-server log, and hosting task log when available. Match timestamps and hook names. Avoid enabling verbose debugging on a public production site without considering whether sensitive information could appear in the log.
Check for recent changes. A plugin update, theme deployment, PHP configuration change, database migration, or firewall adjustment can affect background work. If the site also shows a blank response or fatal error, follow this WordPress white screen troubleshooting guide for a structured log-first process.
For a failed action, test the smallest safe unit. A staging site may allow a manual run without affecting customers. On production, avoid replaying actions that create duplicate invoices, orders, emails, or imports. Confirm whether the task is idempotent, meaning it can safely run more than once.
Database-backed queues deserve special care. A queue can grow when workers fail, but deleting its records may destroy work that someone still needs. Export evidence first and ask the plugin vendor or administrator how to retry safely.
When to escalate the problem
Escalation makes sense when events remain overdue after configuration checks, logs show repeated fatal errors, the server job does not run, or several plugins fail together. It also helps when the site handles orders, tenant communications, access records, or compliance-related tasks. At this stage, WordPress WP-Cron not running troubleshooting should focus on controlled verification rather than repeated configuration changes.
Prepare a concise handoff:
- Site and hosting environment
- Affected hook or plugin action
- Expected and observed times, including time zone
- Recent changes
- Relevant log lines with secrets removed
- Whether request-based WP-Cron is disabled
- Details of any server cron job
This evidence reduces guesswork and helps separate scheduler problems from plugin failures. Google’s Effective Troubleshooting guidance also emphasizes evidence, testable hypotheses, and controlled changes.
Tech Rescue Ops LLC can help when your team needs a careful review of WordPress scheduling, hosting logs, server cron configuration, or failed background actions. Professional remote assistance is especially appropriate before changing production schedules or replaying business-critical tasks.