Open the post and record its status, date and timezone. Verify that it was scheduled rather than left as a draft or pending review. Compare the site timezone with the campaign's intended local time and any seasonal offset changes.

Check the direct public URL as well as the blog listing. A cached listing can hide a post that already published, and an authenticated preview can make an unpublished post look public to its author.

1. Review Site Health for loopback or scheduled-event warnings.
2. Determine whether the site uses normal visitor-triggered WP-Cron or a configured external scheduler.
3. Inspect due events through an authorised supported tool, such as a read-only WP-CLI event listing.
4. Review logs around the intended publication time for a fatal error or timeout.
5. Check whether other scheduled tasks are also overdue, which can indicate a broader runner problem.

A quiet site may not receive a request at the exact due time under the default model. A scheduled external runner can improve regular triggering where the service supports it, but it must be configured and monitored correctly.

If DISABLE_WP_CRON is enabled, verify that the replacement job actually exists and runs. Do not simply disable the default mechanism in the hope that scheduling becomes more reliable.

Use these inspection commands on the selected site to compare future posts with the publication hook. The listings do not publish posts or run due callbacks. Replace the path and URL with the actual installation, especially on Multisite.

wp --path='/home/ACCOUNT/sites/example.com' --url='https://example.com' \
  post list --post_status=future --post_type=post \
  --fields=ID,post_title,post_date,post_date_gmt --format=table
wp --path='/home/ACCOUNT/sites/example.com' --url='https://example.com' \
  cron event list --hook=publish_future_post \
  --fields=hook,next_run_gmt,next_run_relative --format=table

Compare the intended campaign time with both the local post date and GMT date. An overdue event suggests the runner needs attention, while a published direct URL with a stale listing suggests caching. Share only the relevant rows if draft titles are confidential.

Expected result: You can identify whether the post state, timezone, runner or cached listing explains the missed publication before manually publishing or adding another scheduler.

Once the intended timing and cause are understood, publish the article manually or set a new schedule according to the editorial plan. If a coordinated launch or embargo still applies, confirm the current decision before using Publish now.

Check that the post appears once at the expected URL and that notifications or social integrations did not duplicate their actions during retries.

Create a controlled non-sensitive test schedule or monitor the next genuine planned post. Check the event list and logs after its due time, then remove any test content appropriately.

Provide support with the post ID, intended time, site timezone and runner configuration when the issue persists. Avoid deleting all cron events or installing several overlapping missed-schedule plugins, which can obscure the original fault and create additional background work.

• Scheduling a post and checking the site timezone
• Checking WordPress cron events with WP-CLI
• Replacing visitor-triggered WordPress cron with a scheduled task
• Finding the source of a WordPress 404 after a permalink change

• WordPress: Cron
• WordPress: Loopback
• WordPress documentation

• WP-CLI post inventory
• WP-CLI scheduled event inventory