# 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.

- Source canonique : [https://allaux.fr/en/problemes/taches-automatiques-arretees](https://allaux.fr/en/problemes/taches-automatiques-arretees)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Call the task URL by hand in the browser, token included: if it runs, the trigger is at fault, not the script. On WordPress, WP-Cron only fires on visits, unless DISABLE_WP_CRON is true in wp-config.php and a server cron calls wp-cron.php. On PrestaShop, the cron task module URL carries a token that changes whenever the shop key changes.

## 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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.

## A failing task should tell you

> The real fix is not to rerun the task: it is to make a failure produce an alert. A simple email on error, or a dated status file you can check, turns an invisible failure into an incident detected the same day.

## 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. ([/prestashop/problemes/taches-cron-ne-sexecutent-pas](/prestashop/problemes/taches-cron-ne-sexecutent-pas))
- **Cron explained** — What a scheduled task is and how it is triggered. ([/glossaire/cron](/glossaire/cron))
- **Automation** — When a chain of processes deserves rethinking rather than repairing. ([/services/automatisation](/services/automatisation))
- **Connecting a product feed** — If the broken task feeds a comparison site or a marketplace. ([/guides/connecter-flux-produits](/guides/connecter-flux-produits))

## FAQ

### How do I know since when the task stopped running?

The modification date of the file it produces answers immediately. If it writes nothing, the most recent up-to-date record in the database gives the order of magnitude.

### Can I replace a server task with an external service calling an address?

Yes, a common solution when hosting does not allow creating tasks. The address must then be protected with a key, otherwise anyone can trigger the processing.

### Two runs at the same time — is that serious?

It depends on the processing. On an import or a synchronisation, yes: data is written twice or conflicts. A lock preventing overlap is the usual answer.

### The task runs but does nothing. Why?

Often because a condition at the top of the processing is no longer met: a disabled module, an emptied setting, an unreachable data source. The processing log then becomes essential.

### Does a small shop need automated tasks?

It depends what they do. Clearing a cache or cleaning abandoned baskets is useful at any size; synchronising a catalogue with business software only matters if that software exists.