# A module that has to run with nobody watching

> Syncing supplier stock every night, moving an order automatically from one status to another, producing a periodic export: these processes have no user in front of the screen, and that absence changes everything about how they are written.

- Source canonique : [https://allaux.fr/en/modules/module-qui-tourne-en-tache-de-fond](https://allaux.fr/en/modules/module-qui-tourne-en-tache-de-fond)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## What separates background work from a page

A web page is short, triggered by a visitor, and its failure is immediately visible. A background process is long, triggered by a clock, and its failure isn’t seen — unless it was designed to report itself. That is the most important difference, and the one most often overlooked.

So three things are needed from the design stage. A log stating when the process started, what it did and why it stopped. Protection against overlap, so a run that lasts longer than expected doesn’t trigger a second one in parallel on the same data. And the ability to resume, so an interruption halfway doesn’t leave half the work in an uncertain state.

## How triggering actually works

On PrestaShop, a periodic process is a controller called at a regular interval, either by a scheduled job configured on the server or by an outside service calling an address. The server-side scheduled job is the most reliable mechanism, because it depends on no visitor.

On WordPress, the native scheduling mechanism is triggered by traffic: with no visit, nothing fires. On a quiet store that produces processes running hours late, or not at all overnight. The fix is to disable traffic-based triggering and call the mechanism from a server-side scheduled job at a fixed interval. It is one of the most worthwhile interventions on a WooCommerce store that relies on automated processing.

In both cases the called address must be protected: a heavy process anyone can trigger becomes an easy way to bring the server down.

## Execution time is a real limit, not a theoretical one

> A process launched from a web address is subject to the server’s time and memory limits. Past a certain volume it stops with no message, often at the same point, which looks like a bug when it is a limit being hit. Batch processing with resume isn’t a refinement: it is the only way to hold up over time.

## Related pages

- **Cron jobs don’t run** — The diagnosis when the scheduled process never starts. ([/prestashop/problemes/taches-cron-ne-sexecutent-pas](/prestashop/problemes/taches-cron-ne-sexecutent-pas))
- **Task automation** — The wider frame: imports, exports, synchronisations, reports. ([/services/automatisation](/services/automatisation))
- **Cron** — The short definition of the server-side scheduling mechanism. ([/glossaire/cron](/glossaire/cron))

## FAQ

### Why doesn’t my overnight sync start?

On WordPress, almost always because scheduling depends on traffic and nobody visits the site at that hour. On PrestaShop, more often because the server-side scheduled job was never created, or calls an address that has become invalid.

### How often should a process run?

As rarely as the need allows. A five-minute sync processing the whole catalogue costs far more in resources than an hourly one processing only what changed.

### How do I know a process has failed?

Through an alert sent on failure, and a readable log. A silent process failing for three weeks is a common case, and it is always discovered too late, when the data is used.

### Can the process be triggered manually when needed?

Yes, and I always plan for it: a launch button in admin, with the result displayed. That is what allows a fix to be checked without waiting for the next automatic run.