WordPress cron not running — the scheduler that only works when somebody visits

WordPress cron not running — the scheduler that only works when somebody visits



Tópico: WordPress cron not running — the scheduler that only works when somebody visits
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
WP-Cron is the most misunderstood component in WordPress, and the misunderstanding is baked into its name. It is not cron. It does not run on a schedule. It runs when someone loads a page — and if nobody loads a page, nothing happens. On the quiet client sites that most depend on automation, that is a slow, silent, invisible failure.



How WP-Cron actually works


Real cron is a daemon: the operating system wakes it up at the appointed minute whether or not anyone is watching. WP-Cron is a checklist that WordPress glances at during a page request. Someone visits the site, WordPress asks "is anything overdue?", and if so it fires those tasks — during that visitor's request.

Consequences fall out immediately:

•
No traffic, no scheduler. A B2B brochure site with forty visits a day runs its "hourly" jobs whenever someone happens to show up. Overnight, nothing runs at all.

•
Precision is a fiction. A job scheduled for 03:00 runs at the first page load after 03:00 — which might be 09:12.

•
Your visitor pays for it. Heavy scheduled work executes inside a real person's page request. They wait; the job runs.

This is why the standard advice is to turn WP-Cron off and use a real cron. And it is also where the most common catastrophe happens.



The mistake that kills automation silently


Someone reads that advice, opens wp-config.php, and adds:

define('DISABLE_WP_CRON', true);

Then they get distracted, or they hand the site to someone else, or they assume the host "does cron". The second half — actually scheduling the server to call wp-cron.php — never happens.

The result: the scheduler is now completely dead, and WordPress will never mention it again. No warning banner, no email, no log entry. The site serves pages beautifully. Backups stop. Scheduled posts never publish. Update checks stop. And nobody finds out for months — typically when the client asks why the newsletter didn't go out, or when you go looking for a backup that does not exist.

The correct pattern is both halves:



wp-config.php


define('DISABLE_WP_CRON', true);



server crontab — every 5 minutes


*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null



or, better, via WP-CLI


*/5 * * * * cd /var/www/example.com && wp cron event run --due-now

What is actually riding on this

People treat WP-Cron as a background detail. Look at what depends on it:

That last row is the one that catches agencies out. Some form plugins offer a "background sending" option that queues notification emails through Action Scheduler instead of sending them during the request. It makes forms feel faster — and it hands your lead notifications to the very scheduler that is broken. The visitor sees "thanks, we'll be in touch". The email sits in a queue that nothing ever drains. We wrote about this failure in detail, because it is a genuinely nasty one: two independent silent failures stacked on top of each other.



Why nobody notices for months


Because a broken scheduler produces no events. That is worth sitting with for a second.

Every monitoring instinct you have is tuned to notice things that happen: an error, a 500, a slow response, an alert. A dead cron is the opposite — it is the absence of things happening. There is no error to catch, because nothing errored; there was simply nobody there to try.

Uptime monitoring is completely blind to it. The site is up. The homepage loads in 200 ms from six continents. Every check you have is green, and has been green all the way through three months of no backups.

This is the same structural blindness as a store whose orders quietly stopped: systems report events, and the disappearance of an event is not an event. Somebody has to go looking for absence — or set up something that does.



How to monitor that scheduled jobs actually ran


Two approaches, and they catch different failures. Use both.



1. Heartbeat: let the job announce itself


The most reliable check for "did it run" is to make the job say so. Schedule a task that pings a monitoring URL each time it executes; the monitor expects that ping within a window, and alerts you when it doesn't arrive.

This is the beauty of the inverted check: silence is the alarm. If the scheduler is dead, the ping stops, and you hear about it — no false positives, no guessing. It works for anything on a schedule, not just WP-Cron: nightly backups, database dumps, sync scripts. If it should have run and it didn't, you find out today, not in three months when you need the backup.



2. Inside check: is the scheduler even alive?


A heartbeat tells you a specific job stopped. It cannot tell you the scheduler is running but drowning — tasks piling up, hours overdue, on a site whose traffic isn't enough to drain the queue.

For that you need to look from inside. Our WordPress plugin reports two things: whether DISABLE_WP_CRON is set (with no server cron behind it), and how far behind the due tasks actually are. A growing backlog is the early warning that the site is quietly running on fumes — before the backup you needed turns out not to exist.

It sits alongside the other checks that only make sense from inside WordPress: modified core files, plugins with published vulnerabilities, mail going out unauthenticated through PHP-mail, autoload bloat. All invisible from the outside. All quietly expensive.



The rule this all points to


Monitor the things that should happen, not only the things that can go wrong. Error monitoring catches events. Nobody catches absences unless they deliberately decide to — and absences are where the expensive failures live: the backup that never ran, the lead email that never sent, the order that never came, the certificate nobody renewed.

WP-Cron is just the most common example. It is a scheduler that requires an audience, quietly installed on thousands of client sites that don't have one.



FAQ


Why is WordPress cron not running?

Because WP-Cron isn't a real cron: it fires when someone loads a page. Low traffic means tasks run late or not at all. If DISABLE_WP_CRON is set and no server cron replaced it, they never run — and nothing in WordPress will tell you.

What breaks when WP-Cron stops?

Everything scheduled: backups, security scans, scheduled posts, update checks, subscription renewals, follow-up emails, CRM syncs — and, on plugins that queue email in the background, the lead notifications themselves. The site keeps serving pages perfectly throughout.

How do I replace WP-Cron with a real cron?

Set DISABLE_WP_CRON to true in wp-config.php, then have the server call wp-cron.php on a schedule (system cron every few minutes, or wp cron event run --due-now). The fatal mistake is doing the first half without the second.

How do you monitor that cron actually ran?

A heartbeat check — the job pings a monitor each run, and you're alerted when the ping stops — plus an inside check that reports whether WP-Cron is disabled and how far behind the queue is.

Originally published at pingvera.com.

Originally published at pingvera.com.