OpenCart cron jobs run supported tasks on a schedule, such as synchronisation or imports. Adding a command to a hosting panel is only the first step. Reliable operation also needs the correct runtime, a verifiable result and a defined recovery procedure.
Use the extension’s supported entry point
Distinguish a CLI command from an HTTP request to a dedicated endpoint. An extension may support only one method. Take the command from its documentation or settings instead of copying an admin URL from a browser. Examples for OpenCart 4 should not be transferred automatically to OpenCart 3.
Check the PHP executable path, version, extensions and working directory. Console PHP can differ from the web runtime. For HTTP execution, verify HTTPS and the access token without exposing the token in public logs or examples.
Define the schedule and success condition
Confirm the server timezone and interval. If a task takes longer than its interval, another run can overlap it. Spread heavy jobs over time and allow for occasional delays from an external API.
HTTP 200 or a successful shell exit does not necessarily mean the business operation finished. The response may contain an application error or describe only a partial batch. Check processed counts, checkpoints, messages and the last successful completion time.
Make logs useful for recovery
- Start and finish time with a run identifier.
- Channel or task type, without credentials.
- Successful, skipped and failed record counts.
- A safe error code and the next supported action.
Keep the last success separate from the latest attempt. Otherwise a failed run may appear to be a fresh synchronisation. “Check error.log” directs you to evidence; it is not a diagnosis on its own.
Prevent overlap and preserve progress
A module should prevent concurrent work on the same resource and release its lock safely. After an interruption, do not remove a lock blindly: establish that the previous worker has ended. Manual execution also needs to respect an already active run.
Large workloads benefit from bounded batches and saved checkpoints. A message saying the batch timed out but progress was saved calls for checking the checkpoint and using the supported continuation. It does not prove that all work was lost. Conversely, partial progress must not be reported as full completion.
Test the sequence on a small sample: start a run, inspect its log, interrupt only in a controlled staging test and confirm the next run resumes without duplicate writes. This checks the behaviour that matters when production encounters an unexpected interruption.
For Pricer PRO and other integrations, reconcile the task state with the channel’s actual result. Browse ShopX extensions for the appropriate catalogue or order workflow. A managed cron setup consists of a schedule, evidence of completion and a safe way to continue.
Schedule-field reference: cPanel cron jobs; other hosting panels may use different labels.
