Cron not working: a checklist

Listings that stop updating, imports that never finish, and old listings that are never removed are usually one fault, not three. All three depend on the WordPress schedule, so when it stops, they stop together.

Work through these causes in order. They are arranged by how often each one turns out to be the answer.

1. Auto update is off on the task

Open Import Tasks and read the Auto Update Enabled column. A task reading no is not on the schedule. Open it, turn on Enable Auto Update every hour and click Update.

2. The task never completed an import

The hourly sync only runs on a task that has completed an import. That covers a new task nobody has run by hand, and a task whose manual run was interrupted, which stays marked as still running and is skipped every hour afterwards.

If one task stopped while the rest are healthy, this is almost always why. Run it manually and let it reach the completed message.

3. WordPress cron is disabled

Install WP Crontrol, open Tools, then Cron Events. A notice that the DISABLE_WP_CRON constant is set to true means WordPress will not run its schedule on its own. Many hosts set it.

That is not a fault by itself, provided a server cron drives the schedule instead. Ask your host to confirm whether one exists and what it calls. If none exists, add one.

4. The site has too little traffic

With WP-Cron enabled, the schedule only advances when someone loads a page. A new site, a staging site or a site with quiet nights runs its hourly sync far less than hourly. A server cron removes the dependency on visitors.

5. The queue is backed up

Go to Tools, then Scheduled Actions. Look for these signs:

1. A recurring action that is pending and days past due, often with a WordPress notice about a past due action.
2. A message about the maximum simultaneous queues already being in progress. That is a lock left behind by a run that was killed, and it blocks everything after it.
3. Several duplicate pending import actions with identical arguments, created minutes apart. Earlier runs died and were re-queued.

Cancel the duplicates and the stale lock, then start one import manually and watch whether the queue advances.

6. The web server is killing the run

This is the cause people reach last and it is often the real one. It survives every standard fix, because the limit is above PHP and does not appear in Site Health.

One import task is queued as a single action that works through all of its batches, so it can legitimately run for many minutes. If your web server caps a request at 300 seconds, the run is killed at 300 seconds. Since wp-cron.php is fetched over HTTP, a server cron that calls that URL goes through the same web server and hits the same cap.

1. Ask your host for the web server error log around a failed run. Lines such as a read data timeout, an upstream timeout, or end of script output before headers on wp-cron.php confirm it.
2. Run the schedule and the queue through WP-CLI instead. The shell has no web request timeout, and the same action that always failed completes.
3. Split large tasks into narrower ones so each run finishes inside the host’s limits.
4. Or raise the timeout with your host, if they allow it.

7. The MLS connection is not valid

The hourly run exits at once if the connection test is not passing or the API token cannot be obtained. Open MLS Import Settings, MLS/RESO Api Options, and confirm both connection messages are green. An expired MLS agreement produces exactly this: everything configured correctly and nothing updating.

8. Nothing has actually changed

Before treating a stale Last Action date as a fault, check Import History for rows from scheduled runs. A small or quiet task can genuinely have nothing to report for days while the schedule is working.

What to collect if it persists

1. The web server error log from around a failed run. This is the decisive one.
2. Site Health, then Info, then Server: the PHP memory limit and maximum execution time.
3. Whether DISABLE_WP_CRON is set in wp-config.php, and whether a system cron exists and what it calls.
4. Whether WP-CLI is available on the account. Most managed hosts have it.
5. Plugin logs: turn logging on under Tools, let one run happen, then send logs/status_logs.log and the dated cron log. Turn logging off afterwards.

Frequently asked questions

Will adding a server cron for wp-cron.php fix an import that never finishes?

Not if a web server timeout is killing it, because that cron request goes through the same web server and is cut off at the same point. WP-CLI is the method that avoids it.

Could another plugin be blocking MLSImport’s schedule?

Indirectly, yes. All scheduled actions share one queue, so a plugin filling it with long running jobs delays everything behind it. The Scheduled Actions screen shows what is queued and who owns it.

Is it safe to cancel pending MLSImport actions?

Yes. Cancelling a queued action stops work that has not started and deletes nothing. Start the import again afterwards, and it re-queues cleanly.

Can you fix the cron setup for me?

We can identify the cause from your logs and tell your host exactly what to change. We cannot verify a server side limit without full access to the site and permission to run tests, so the host has to confirm the cap and lift it.

Related

1. Setting up a real server cron
2. Checking that auto update is running
3. Running a manual import and stopping one
4. Avoiding overlapping import tasks

Send us the web server error log and the plugin logs from one failed run and we will tell you which limit is stopping it.