WordPress schedules work — sending emails, taking backups, publishing scheduled posts, clearing caches — and runs it when someone visits the site. On a quiet site, or with caching in front, those visits may not reach PHP at all, so nothing runs. Failures are silent, which is why this is usually noticed weeks later when a backup is needed.
Before you buy, one quick look
Read-only.
In wp-admin go to Tools → Site Health. If scheduled events are failing, WordPress reports it there in plain language.
Also think about what has silently stopped — scheduled posts that never published, backups with no recent entry, order emails that stopped arriving. That list tells us how long it has been broken, which is useful.
WP-Cron not firing - diagnosis & fix
Scheduled tasks are not running, so backups, emails and publishing silently fail. We find why cron is not firing and set it up so it runs reliably.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Scheduled posts never publish | This fix covers it |
| Backups have stopped running | This fix covers it |
| Emails not sending at all | Contact form or SMTP diagnosis |
| Site Health reports failing events | This fix covers it |
| Everything runs but very late | This fix covers it |
What you are seeing
- Scheduled posts staying as missed schedule instead of publishing
- Backups, reports or cleanups with no recent runs
- Site Health warning that scheduled events are not running
- Tasks running eventually, but hours late
- Order or notification emails arriving late or not at all
Common causes
- WP-Cron disabled in wp-config without a real cron job replacing it
- Full-page caching serving every visitor without ever reaching PHP
- Very low traffic, so nothing triggers the queue
- A stuck task blocking everything behind it in the queue
- A security rule blocking the request WordPress makes to itself
What we do
- Take a full backup before touching anything
- Confirm whether cron is firing at all, and how often
- Inspect the queue for stuck or duplicated tasks
- Clear blockages and remove orphaned events from removed plugins
- Replace visitor-triggered cron with a real server cron job where the host allows
- Verify tasks run on schedule over a full cycle
What is included
- Scheduled tasks running reliably, on time
- A server-level cron job configured where possible, rather than depending on traffic
- The task queue cleaned of stuck and orphaned events
- A note on what was failing and for how long
Not included
- Fixing a plugin whose scheduled task is itself broken — diagnosed, then quoted
- Full email deliverability setup, which is a separate service
- Recovering backups that were never taken while cron was broken
- Design changes or content work
Questions about this fix
How long has this been broken?
Often longer than people expect, because nothing announces it. The queue and the last-run timestamps usually tell us, and that date is in the note — it matters most if backups are among the things that stopped.
My scheduled posts publish, just late. Is that the same problem?
Yes, a milder version. Traffic-triggered cron means tasks run whenever the next visitor arrives. On a quiet site that can be hours. A real cron job fixes the timing entirely.
Does caching cause this?
It is one of the most common causes. Full-page caching is meant to avoid running PHP, and cron needs PHP to run. The two work against each other unless cron is moved to the server, which is what we do.
Are my backups affected?
Very possibly, and it is the first thing to check. Most backup plugins rely on cron. If cron has been dead for weeks, the most recent backup may be weeks old, and you would not know until you needed it.
Does a real server cron job fix this permanently?
It's the more reliable long-term answer, yes — a real cron job runs on schedule regardless of visitor traffic, unlike WordPress's own approximation. We set that up as part of this rather than just patching the symptom.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.