A module that has to run with nobody watching

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.