WP-Cron is WordPress’s scheduled-task system. In ordinary page-triggered operation, it checks for due work when a page loads, so a scheduled time is not proof that a task completed then. Diagnose missed work by recording the event, its trigger and the observed result separately, with the relevant time zones attached.
Begin with the task that matters to the business. A scheduled article, an update check and a plugin’s background operation have different owners and different evidence of completion. Writing “cron is broken” hides those distinctions. Record the named task and the symptom before changing how the site schedules work.
Why can a scheduled time differ from a completed run?
The official WP-Cron introduction explains that WordPress checks its scheduled-task list on page loads and calls work that is due. It describes scheduled publishing and update checks as examples of core features using that system. In that ordinary mode, WP-Cron does not run continuously like a system scheduler.
This distinction matters when interpreting a timestamp. An event can be scheduled for a time without a page-triggered check occurring at that moment. The documentation describes queued work being considered at the next opportunity. Keep that scheduling explanation separate from evidence that the task’s own callback succeeded: a queue entry and a finished business action answer different questions.
Ask the maintainer which trigger arrangement the actual site uses. Do not infer its configuration from the fact that WordPress is installed. Record the arrangement and the relevant site rather than assuming that every site on a hosting account behaves alike. Any later proposal to change that arrangement should have its own scope and verification plan.
How do recurring intervals differ from clock appointments?
The WP-Cron scheduling reference describes recurrence using a first-run time and an interval expressed in seconds. It distinguishes that interval approach from a traditional calendar-style instruction. This is useful context when someone expects a recurring task to mean a particular minute on every wall clock.
WordPress documents default intervals and a filter for adding custom ones. A custom label in a schedule should therefore be investigated, not treated as self-explanatory. Ask the component owner what the configured interval represents and what outcome the task is intended to produce. Preserve that explanation with the task record.
Keep proposed business timing separate from software configuration. For example, the person responsible for an article may require it to be publicly visible before an announcement. That business requirement needs a publishing and verification arrangement; choosing a recurring interval alone does not establish that the requirement has been met.
What can an event listing tell you?
Where WP-CLI is available to the responsible administrator, its documented wp cron event list command displays scheduled events. The reference lists default fields including the hook, next-run information and recurrence, with options to select fields or an output format.
For example, the documentation supports this listing command from the intended WordPress installation:
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence --format=json
Confirm the target installation before using an administrative command. Retain the resulting listing with its capture time and configuration context. Do not publish a raw administrative export as part of a support conversation if it contains information the recipient should not receive.
The listing helps identify the scheduled record. It is not a report that the underlying work finished. Compare it with the evidence appropriate to the task, such as the public article that should have appeared or the component’s own operational record. Avoid manually running or rescheduling unrelated jobs just to make a general status screen look healthier.
| Question | Evidence to record | Interpretation to keep separate |
|---|---|---|
| Which task is affected? | Hook or component name and business owner | A vague claim about every background job |
| When is it scheduled? | The displayed next-run value and its time zone | Proof that the task completed at that time |
| What triggers checking? | The actual site’s trigger configuration | An assumption based on another hosted site |
| What result is expected? | The named public or operational outcome | Merely finding an event in the queue |
| What happened? | Observed result and the relevant component evidence | A successful outcome inferred from silence |
This is an original diagnostic record. Fill it with observations from the named site rather than generic claims about how a typical host operates.
How should you investigate a missed task?
Start with the affected outcome. If a scheduled article did not appear, record its intended publication details and inspect the article’s actual status. If a plugin’s job is involved, ask its owner which record demonstrates success or failure. Do not apply a publishing diagnosis to an unrelated integration merely because both use scheduled events.
Next, align the clocks used in the investigation. Write the time zone beside the editor’s expectation, the captured listing and the relevant operational record. Convert them to a common basis before comparing them. This is a proposed investigation practice; it avoids treating two differently labelled clock readings as a delay without doing the comparison.
Then identify the trigger arrangement and the task record. Record the exact configuration that was inspected and any uncertainty about it. If the event is absent, investigate the component responsible for scheduling it. If the event is present but the expected outcome is missing, investigate the trigger and callback evidence without declaring either one successful merely because the other exists.
Keep the correction bounded. Name the affected task, the proposed change and the result that would demonstrate recovery. Ask the maintainer to explain the impact before changing a shared scheduler or invoking jobs that can send messages, synchronise records or perform other business actions. The aim is to repair the observed failure, not to run every pending operation indiscriminately.
Original scheduled-publication rehearsal
Use an isolated test copy to rehearse a simple publishing case. This original exercise is intended to produce evidence about that test configuration; it does not claim that Spout has executed it or that every plugin behaves like a WordPress post.
Create a clearly fictional article and agree when it should become visible. Record the test environment’s clock and the selected publication time with their time zones. Capture the relevant schedule information before the intended run. Keep the content recognisably fictional so it cannot be mistaken for an approved announcement.
Observe the configured trigger and then inspect the article’s actual state and public test address. Record what appeared, the observation time and any relevant error evidence. Distinguish “the article is visible” from “the event was present in the listing”. Both observations can be useful, but neither should be substituted for the other.
If the result differs from the agreed expectation, change one relevant part of the test configuration at a time and retain the before-and-after observations. Ask the component owner to explain the result before proposing an equivalent production change. Keep messages, payment actions and other live integrations outside this fictional publishing exercise.
Finish with a handover note: the affected task, its owner, the trigger arrangement, the timing requirement, the observed outcome and the remaining question. For related administration work, see WordPress services and hosting. Get started with that record if you need help defining the investigation.
By Spout Team. AI-assisted drafting by Codex using the linked primary WordPress documentation.