Custom WordPress website development
in San Francisco

WordPress runs its scheduled tasks in an unusual way. Instead of a real timer on the server, it checks for due tasks when someone visits a page. On a busy site this works. On a quiet one, a post scheduled for nine in the morning may appear at noon, when the first visitor arrives.

Posts are only one example. Plugins use the same system for backups, email digests, cache clearing, feed imports and subscription renewals. A delay or a failure affects all of them, often without any visible error.

Heavy tasks cause the opposite problem on busy sites. A visitor triggers a long import, and their page loads slowly while the task runs. Several visitors at once can start the same task in parallel.

The usual fix is to switch off the visitor trigger and use a real server schedule instead. A system cron job calls the WordPress task runner every few minutes, whatever the traffic. Most managed hosts support this, and it takes a few lines of configuration.

Then make the schedule visible. Tools exist that list every scheduled event, when it last ran, and when it will run next. Reviewing that list often reveals tasks left behind by plugins removed long ago, still firing and still failing.

Long jobs should be broken into smaller pieces. An import of thousands of products can process a batch at a time and schedule the next batch, instead of trying to finish everything in one request that times out.

Failures must be noticed. A task that throws an error should write to a log, and important tasks, such as backups, should send an alert when they do not complete.

Staging and production must not share schedules carelessly. A copy of the live site running on a test server can send real emails to real customers when its scheduled tasks fire. Disabling outgoing mail on staging prevents that embarrassment.

After any migration, check the schedule. Every time. Moving hosts or changing the server setup is the most common moment for cron to stop quietly.