WordPress Cron and Hosting: Check Scheduled Tasks Before They Go Missing

Guides / Scheduled website tasks

Documentation checked: October 5, 2026. HRL combines official documentation with practical investigation and acceptance checks. This is not a hands-on scheduler test or a certification of any host.

A working website does not prove that its scheduled tasks ran. Publishing, maintenance and plugin workflows may rely on background scheduling. Identify the task, the trigger and the completion evidence separately before blaming traffic or changing the hosting plan.

What default WP-Cron does

WordPress’s cron handbook explains that default WP-Cron checks due tasks during page loads rather than running continuously. A task scheduled for one time can therefore run later if the relevant WordPress execution does not occur until later.

That model matters for a quiet site, but low traffic is only one possible explanation for delay. A trigger may run while the application task itself fails. A host may also have configured an independent scheduler already. Record the actual configuration before replacing it.

Distinguish the trigger from the task

HRL recommends writing an acceptance check for the important outcome. For example, a reminder workflow needs evidence that the job ran and that the intended test inbox received the message. A mail delivery issue can remain after successful execution; use the email delivery checklist for that part of the route.

When to ask about a host scheduler

The WordPress system scheduler guide describes running WP-Cron from an independent scheduler and then disabling the page-load trigger. Do not disable the existing trigger before the supported replacement has been configured and verified.

Ask the host which method it supports, the allowed interval, how to inspect failures and who maintains the configuration. Follow the plugin’s documented scheduling requirements. A blanket “once per day” or “every minute” recommendation is not a substitute for the task’s actual needs.

An independent trigger improves control over when work starts; it does not guarantee that every callback finishes successfully or that an external service responds. Define the acceptable delay and the escalation contact for the workflow.

Trace a delayed job before rerunning it

Record the task name or hook, plugin responsible, scheduled time, timezone, last observed completion and relevant error. Check whether it is a future task, an overdue task or a recurring failure. Review recent migrations, configuration changes and plugin updates alongside the incident.

If the runner starts but work fails, investigate the recorded cause. PHP request capacity, memory limits and database constraints are separate checks. None is established as the cause merely because a task is late.

Before retrying a task that sends messages, changes orders or calls a payment service, confirm its prior outcome and the application’s supported retry procedure. A second attempt can have business effects. Use controlled test records when rehearsing the process.

Check plugin queues separately

Action Scheduler’s FAQ explains that the library normally works alongside WP-Cron and can be started through other supported methods. It is not simply a replacement for every WordPress scheduled event. A successful cron trigger does not by itself prove the plugin queue is healthy.

For a store using that library, follow the WooCommerce scheduled-actions guide. For appointment workflows, use the booking hosting guide to establish whether WordPress or an external service owns the schedule.

Trace a reminder across all three stages

For a hypothetical appointment reminder, record when the runner started, whether the reminder job completed and whether the controlled inbox received the message. If execution completes but receipt fails, investigate delivery. If the runner never starts, investigate scheduling. This evidence prevents a mail problem from being treated as a reason to replace WP-Cron or increase hosting capacity.

Verify scheduling after a migration or change

Include the runner configuration in the migration inventory. Confirm the intended timezone, task registration, execution and outcome on the destination. Prevent staging from sending real customer messages or performing live business actions while testing.

HRL recommends a dated record of the responsible service, required interval, last accepted test and recovery contact. Monitor missed outcomes as well as whether the website is online. Do not mark the workflow ready merely because the homepage loads.