My automated tasks no longer run
A scheduled task has nobody to read its error message. It runs at night, with no browser and no user, and when it fails, nothing says so. The problem surfaces days later, through a stale feed or wrong stock. It is the quietest and costliest failure in this section.
Two very different ways to schedule
There are two mechanisms, often confused. The first is a task scheduled at server level: the system triggers a command at a fixed hour, independently of traffic. That is reliable, but it needs hosting access to create and check.
The second is triggering on a visitor’s page load: the CMS checks on every page whether a task is due, and runs it if so. Simple to set up, but it means a shop with no visitors runs nothing, and a long task is interrupted along with the page that triggered it. A good share of "tasks that no longer run" are really tasks of this second type on a site with little overnight traffic.
Checking whether it really runs
-
Look for a trace of the last run
Date of the generated file, last line of the log, timestamp in the database. With no trace, you cannot tell whether the task fails or is never triggered: two distinct problems.
-
Run the command by hand
If it works manually but not automatically, the problem is in the scheduling, not the processing. That test splits the field of causes in two.
-
Check the execution context
A task launched by the server has no session and no logged-in user, and sometimes a different PHP version from the site. Processing that assumes a user fails silently.
-
Check the duration
If the task takes longer than the interval to the next run, two runs overlap. Depending on the processing, that produces duplicates or a database lock.
-
Check access tokens
Many tasks are triggered by an address protected with a key. A key regenerated during a reinstall invalidates every existing schedule, with no message at all.
What breaks a schedule without warning
- A hosting change: server tasks are not copied with the files and must be recreated.
- A PHP version change: the scheduled command may call an executable that no longer exists under the same name.
- Moving the site into another directory: the absolute path written in the task leads nowhere.
- An uninstalled module taking its own tasks with it, or leaving orphans that fail on every attempt.
- An expired password or access key for an external service.
Carry on with the right page
-
Cron tasks on PrestaShop
How it works and the traps specific to PrestaShop.
-
Cron explained
What a scheduled task is and how it is triggered.
-
Automation
When a chain of processes deserves rethinking rather than repairing.
-
Connecting a product feed
If the broken task feeds a comparison site or a marketplace.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.