Job wpcron-scheduled-posts-and-tasks-not-running · revised 11 October 2026
Make scheduled WordPress posts and timed tasks run on time, with a real scheduler
Find why scheduled posts show "Missed schedule" or timed tasks run late, set up a dependable trigger, and prove it with three harmless scheduled test events and a clean event list.
You might be seeing
- "Missed schedule" appears on a scheduled post
- Posts publish only when someone visits the site
- Timed emails, cleanups or backups run late or never
- A caching plugin was added and scheduled things stopped
No passwords, keys, card details or admin invites needed to start.
What usually happened
WordPress does not run a clock. It checks its task list when a visitor loads a page and runs what is due. On a quiet site, behind some caches, with the built-in trigger switched off and nothing in its place, or on a host that blocks the site calling itself, tasks wait until something nudges them, or never run.
Who it’s for: Owner or editor of a WordPress site that relies on scheduled posts, timed emails, cleanups or backups.
Usually starts when: A post set for 9am published at noon or not at all, a scheduled email never went, or an admin warns that a scheduled task failed.
The result: Three test events scheduled on the live site run within an agreed tolerance of their due times, and the list of scheduled events shows nothing overdue beyond that tolerance after an agreed observation period. No post is created or published for the test.
Check whether this job fits
A few short questions. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Look at the Site Health screen
In the admin open Tools, then Site Health, and read the Status and Info tabs.
Look for: Any warning about scheduled events or loopback requests. Share the wording only.
Check the configuration file for the switch
Ask your site holder whether the site's configuration file defines DISABLE_WP_CRON.
Look for: A line setting it true. If it is true and no scheduled job calls the site, that alone explains tasks that never run.
What you get
- A note naming the cause with the evidence
- The scheduler set-up steps for your site holder, with the exact setting changes
- The test-event results and the event list before and after
- A list of any task that keeps failing and which plugin owns it
- Steps to undo the change
Included
- One single WordPress site
- Reading the list of scheduled events and the settings that affect them, including any switch that disables the built-in trigger
- Finding the cause: low traffic, a disabled trigger with no replacement, a cache or security rule blocking the trigger, a host restriction, or a task that errors
- Setting up a trigger every few minutes through the host's scheduler or an outside scheduler you hold, and setting the matching site option
- A safe live test: three test events, each under its own name that nothing on the site listens to, due at least ten minutes apart, added by your site holder, who first checks that no action is attached to it (the events screen or the "actions" field of WP-CLI's event list shows none), while we direct the steps
Not included
- Repairing a plugin's own task code that throws errors
- Backlogs in a shop's order or subscription task queue
- Moving to a different host
- Replacing a backup, email or reporting plugin
- Guaranteeing the second a task runs
- Applying the change on the live host ourselves
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Three test events with different marked names, due at least ten minutes apart, have each run by their due time plus the agreed tolerance: none is still listed as pending when the list is checked at that time. The tolerance is never smaller than the scheduler interval
Evidence: The event list at set-up, showing no action attached to any test event, and at each check time, with the due times and the tolerance written beside it
After the agreed observation period the list of scheduled events shows no event overdue beyond the tolerance, except any listed as failing for plugin reasons, and the Posts list shows no new "Missed schedule" post
Evidence: Screenshots of the event list and the Scheduled posts list at the start and end of the period
The configuration setting and the scheduled job are consistent: either the built-in trigger is active, or it is switched off and a scheduled job requests the site's trigger at the agreed interval
Evidence: The setting value and the scheduler entry with secrets removed
No test event is left on the live site and no post was created for the test
Evidence: The final event list and the Posts list, sent by your site holder
Sign-off. You sign off after your site holder applies the changes, the three test events run within the tolerance, the observation period ends with a clean event list and the test events are gone.
If it fails. If the checks do not pass, you do not pay, and you keep the findings.
When it fits, and when we stop
It fits when
- The host provides a scheduler or you can use an outside one that requests a web address
- Your site holder can edit the site's configuration file and the host's scheduler
- Your site holder can add and list scheduled events on the live site, with WP-CLI or an events screen such as the one in the WP Crontrol plugin (installed by them, and removed afterwards if you wish)
- You can show an example of a post or task that ran late
- A staging copy exists, although the final test happens on the live site
We stop and tell you if
- The host forbids all scheduled requests and loopback requests and will not change that
- The tasks are failing inside plugin code, not being triggered
- The site is a multisite network
- Nobody can edit the configuration file or the host scheduler
- Nobody can add and list scheduled events on the live site, so the trigger cannot be tested without publishing something
What could go wrong
The change is one configuration setting and one scheduled job, both listed in the handover. Removing the job and restoring the setting returns the site to the built-in behaviour at once.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Switching off the built-in trigger without a replacement stops all scheduled tasks | The two changes are made together, in the stated order, and the test events prove the replacement works. |
| A trigger that runs too often loads the server | We choose the interval with you and your host and watch the event list for pile-ups. |
| A live test reaches readers, subscribers or other systems | The test uses events, not posts: each is under a marked name that nothing on the site listens to, so running it does nothing and nothing is published, sent or shared. If the event list shows that something does listen to one, the test stops and the event is deleted. |
| Two test events under the same name are silently dropped | The three test events have three different names and are due at least ten minutes apart. |
A second reviewer checks that the scheduler request cannot be abused, that no secret is in the notes, and that the test results match the claim.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Read the event list and the settings that affect scheduling, and record which events are overdue and by how long
- Find the cause by testing the trigger address, checking for blocks and reading errors from failing events
- Prepare the exact scheduler and configuration changes for the host
- Your site holder applies them, then adds three test events on the live site and sends us the event list at set-up and after each due time plus the tolerance
- Independent review of the evidence and of the undo steps
- Hand over the note, the results and the list of tasks that still fail for plugin reasons
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, plugin licence and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a monthly check that scheduled tasks are still running on time.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- A small plugin can publish posts that missed their schedule when someone visits. It treats the symptom and does not make timed tasks reliable.
- Some hosts have a one-click option that replaces the built-in trigger with a real scheduled job; ask your host first.
Questions
Why do my posts only publish when someone visits?
The built-in scheduler checks its list when a page is loaded. On a quiet site that can be a long time after the set time.
Will you publish test posts on my live site?
No. The live test uses three harmless scheduled events that nothing listens to, so no post is created, published, emailed or shared. Your site holder adds and removes them.
Is the exact second guaranteed?
No. We set an interval and a tolerance with you and test against them.
What if a plugin's task keeps failing?
We tell you which plugin owns it and what the log says. Repairing the plugin's code is outside this job.
Send an enquiry
Send us
- Which posts or tasks ran late, what time they were set for and when they ran
- Whether the site is quiet most of the day
- The hosting provider and the cache plugin or host cache in use
- Whether anyone changed the configuration file or added a cron job
- Any "Missed schedule" or task-failed message, with personal details removed
Later, once you agree
- A staging copy for reading settings, or a screenshare with your site holder
- The host's scheduler details, applied by your site holder
- Your site holder's agreement to add three test events on the live site, each under a marked name that nothing listens to, and to send us the event list at set-up, at each due time plus the tolerance, and at the end of the observation period
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You keep the hosting account and the live site. We prepare and explain the set-up; your site holder applies it, adds and checks the three test events and deletes any that are still listed afterwards. We do not log in to the live site, and no post is created or published for the test.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “wpcron-scheduled-posts-and-tasks-not-running” as the subject.