Scheduled tasks

Scheduled tasks are background jobs the application runs at an interval: sending the e-mail queue, cleaning up guests, generating the sitemap. They run inside the web application, so they only run while it is running.

The task list

Open System → Maintenance → Schedule tasks.

Schedule tasks: Send emails, Delete guests, Clear cache, Update currency exchange rates, Generate sitemap XML file, End of the auctions and Cancel unpaid and pending orders, with enabled, stop on error, last start and last success dates and Run now
The schedule tasks. "Do not forget to restart the application once a task has been modified."
TaskWhat it does
Send emailsSends messages from the queue. Must be enabled, or no e-mail leaves the store.
Delete guestsRemoves old guest customer records (see the system settings for the age).
Clear cacheEmpties the cache at the interval.
Update currency exchange ratesFetches rates from the exchange rate provider when auto update is on.
Generate sitemap XML fileWrites sitemap.xml for search engines.
End of the auctionsCloses auctions whose end date has passed and picks the winners.
Cancel unpaid and pending ordersCancels orders unpaid for longer than the days set in the system settings.

Plugins can add their own tasks. Run now runs a task immediately.

Configure a task

Editing the task Delete guests: enabled, stop on error, time interval 1440 minutes, machine name and store
A task: interval, machine and store.
FieldWhat it does
EnabledWhether the task runs.
Time interval (in minutes)How often it runs.
Stop on errorDisables the task after a failure, instead of retrying at the next interval.
The name of the machineOn a web farm, the task runs only on the server with this name. Empty = every server that runs the application.
StoreThe store whose context the task runs in (for store-specific data such as the sitemap).

Restart the application after changing a task, as the notice on the list says.

Several servers

When the store runs on several instances (for example several pods in Kubernetes), every run of a task is claimed atomically in the database, so exactly one instance executes it - no extra setup is needed. Use The name of the machine only to pin a task to one particular server, for example the one that holds files the task writes; in Kubernetes that requires stable pod names (a StatefulSet). See Running in production: Docker and Kubernetes.

Question not answered here? Ask the community on GitHub Discussions ↗