A scheduled WordPress task needs a working trigger, a runnable job and a visible result. I check all three when posts miss publication times or a background report stops moving. A healthy server timer alone cannot tell me which stage has failed.
I follow one controlled example from its scheduled time through execution to completion. That separates a missing trigger from a job which started and stopped, or a result which is already saved but still hidden behind cached output.
Separate the trigger from the work
WordPress normally checks for due tasks during page loads. A system scheduler provides an alternative trigger, which is useful when relying on visits does not fit the site. The WordPress scheduler guide explains that arrangement.
A direct local PHP or WP-CLI command also avoids depending on public HTTP routing for the trigger. It still needs the right runtime, filesystem access and WordPress installation. The WP-CLI cron command can run events which are due; that is not a promise that a plugin’s multi-step process has reached its final result.
Follow one controlled example
For scheduled publishing, I use a test post whose intended state and time are clear. I check that it is actually scheduled, rather than a draft with a future date entered, and account for the site timezone when comparing it with server logs.
Then I follow it through the queue, the worker invocation and the saved post status. Finally I check what a reader sees. A cached page can keep showing an older state after WordPress has already changed the underlying record. That is a separate stage of the investigation.
I do this on staging or with an agreed live example. Repeatedly running every due event while investigating one post can also run unrelated emails, imports or other work.
Make completion observable
For a longer job, I want a small amount of useful state: when it started, when it last made progress, which step it reached and when it finished. I also want to know whether the next step is queued. A process marked “running” with no recent progress and no continuation needs attention even if the server’s minute-by-minute timer is healthy.
I keep error details useful without filling logs with private payloads or credentials. Counts, stage names and a consistent run identifier usually make it easier to follow the sequence. The last completed run should stay visible while a new one is in progress.
Plan for a worker stopping halfway through
A background job can outlive one request. I save progress at sensible boundaries and make retries safe before adding automatic recovery. Otherwise a retry can repeat an email, import the same record twice or apply the same operation again.
I also check the lock’s lifetime and recovery behaviour. Overlap prevention should not leave a dead worker permanently blocking the queue. Changing the timer interval alone cannot fix a lost continuation or a job which never records completion.
The same check applies outside cron. A migration can report success while leaving an editorial workflow unfinished, which I cover in checking drafts after a content migration.
This sits alongside my note on cron and shared temporary data: reliable scheduling needs both a working trigger and consistent application state. I judge it by the completed result, with enough evidence to explain where an unfinished run stopped.