PrestaShop cron not running: the invisible failure

The failure nobody notices

A PrestaShop cron that is not running throws no visible error. The store works, orders come in. But the product feed sent to comparison sites is three weeks old, stock no longer syncs with the ERP, abandoned basket reminders never go out, and the month's accounting export is empty.

The merchant finds out from a third party: a customer ordering something that is out of stock, or an accountant chasing a file. By then, several weeks of damage have piled up.

The misunderstanding at the root of it

The ps_cronjobs module is an internal scheduler, not a trigger. It holds the list of tasks and knows which one is due, but it does not wake up on its own: a real scheduled job, configured with your host, has to call its URL at regular intervals.

Plenty of installations stop right there: the tasks are created in the back office, everything looks correct, and nothing will ever run. The module sometimes offers to trigger itself off visitor traffic, which is unpredictable and useless for a job that has to run at a fixed time.

The five real causes

1. No scheduled job on the hosting side. Check your hosting control panel, under "scheduled tasks" or "cron". If the list is empty, you have found it.

2. The wrong PHP version. This is the shared hosting trap. Scheduled jobs run under PHP on the command line, whose version is often different from the one the site uses. The script then lands on an old PHP build and fails immediately, with nobody reading the output. You have to give the absolute path to the right interpreter:

/usr/local/php8.2/bin/php /home/compte/site/modules/ps_cronjobs/cron.php

3. An invalid token. The task URLs contain a security token. It changes when the module is reinstalled, or when the configuration changes. Every task registered with your host then returns an authorisation error, silently.

4. A blocked call. A store behind HTTP authentication, a web application firewall rule, or an IP address restriction returns an error before the request ever reaches PrestaShop.

5. Execution time exceeded. A heavy task, such as rebuilding the search index or a large catalogue export, goes past the allowed limit and stops halfway. Worst case: it leaves data partially processed.

A three-minute diagnosis

Test 1: does the task work over HTTP? Copy the full task URL, token included, and open it in a private browsing window. If it runs, the problem is not in PrestaShop but in the external trigger.

Test 2: does the command line work? Run it over SSH with the absolute path to the PHP interpreter. A syntax error message points to the wrong PHP version.

Test 3: what does the log say? Always add an output redirection to your scheduled job:

wget -q -O - "https://boutique.fr/modules/ps_cronjobs/cron.php?token=XXXX" >> /home/compte/logs/cron.log 2>&1

Without a log, you are diagnosing blind. This is the highest-value change in this whole article.

The configuration we recommend

Prefer an HTTP call to command-line execution for PrestaShop tasks. With wget or curl, the script runs in the same context as the site: same PHP version, same environment variables, same permissions. That removes the biggest source of discrepancies.

Space the tasks out. Three catalogue exports fired off in the same minute will overload the server and make each other fail. Stagger them by a few minutes.

Pick quiet hours for heavy processing, taking your actual trading hours into account.

Set a time limit on your heavy scripts and break them into batches. An export of 50,000 references should be handled in slices, with a resume point.

Monitor it, or none of this counts

A silent cron remains an invisible failure, however well configured. The only real protection is to monitor that it runs.

The principle is simple: at the end of its run, your job calls a check-in URL provided by a monitoring service. If that call does not arrive within the expected window, you get an alert. You are told when a job has not run, not just when it errors, and that is precisely what is missing here.

Failing an external tool, a weekly check is enough to limit the damage: look at the date of the last generated feed, the date of the last accounting export, and how fresh the stock sync is.

On a related note, reminder emails that never go out are often down to a silent cron rather than a sending problem: see diagnosing PrestaShop emails.

Make your scheduled tasks reliable

We audit your tasks, fix the way they are triggered and put monitoring in place. See our e-commerce store management service.