How CS-Cart Actually Runs Background Work

CS-Cart does not have a resident daemon sitting in memory waiting to process jobs. Instead it ships a lightweight internal scheduler that must be poked from the outside at regular intervals. That poke is a single HTTP or CLI call to a dispatcher endpoint, and on managed shared hosting it is almost always wired up as a cron job through cPanel or DirectAdmin. Each time the scheduler runs, it checks its own task table and decides which jobs are due: product and inventory imports, abandoned cart reminders, order status notifications, subscription billing in CS-Cart Multi-Vendor, sitemap regeneration, and cleanup of expired sessions, logs, and compiled cache.

The endpoint you are triggering lives at cron.php in the store root, and it expects a secret key so random visitors cannot hammer it. A typical call looks like https://yourdomain.com/cron.php?dispatch=cron&cron_password=YOUR_KEY. The password is defined in the admin panel under Administration → Scheduler (older 4.x builds place it under Settings → General as the "Cron password"). If you have never set this up, the symptom is subtle and frustrating: the store works, pages load, but imports sit in "queued" forever, email notifications arrive late or never, the sitemap goes stale, and the var/cache directory balloons because nothing is pruning it.

The important mental model for shared hosting is that CS-Cart batches almost all deferred work behind this one scheduler. If the external cron is missing, misconfigured, or silently failing, every background feature degrades at once. Because you are an unprivileged hosting user, you cannot inspect a system-wide crontab or restart a worker service. Everything you need, however, is reachable through the control panel cron manager, the admin Scheduler screen, and the local error_log files that CS-Cart and PHP write inside your account.

Configuring the Cron Trigger in cPanel and DirectAdmin

Start by confirming the cron password. In the admin panel open Administration → Scheduler, note the password shown in the instructions box, and copy the exact command string CS-Cart suggests. It will reference either a URL or the PHP binary path. On LiteSpeed-backed shared hosting the CLI method is more reliable and avoids counting against web request limits, so prefer it when the panel exposes a PHP path.

In cPanel Jupiter, go to Advanced → Cron Jobs. Under "Add New Cron Job" set the schedule to every five minutes and add the command. The CLI form, using the CloudLinux alt-php binary that matches your domain's selected version, looks like this:

*/5 * * * * /opt/cpanel/ea-php82/root/usr/bin/php -q /home/USERNAME/public_html/cron.php --dispatch=cron --cron_password=YOUR_KEY >/dev/null 2>&1

If your account uses the CloudLinux PHP Selector rather than MultiPHP, the binary path may instead be /usr/local/bin/php or an alt-php path such as /opt/alt/php82/usr/bin/php. Confirm the correct version in cPanel → MultiPHP Manager so the CLI interpreter matches the version your site runs on; a mismatch can load the wrong extensions or an older OPcache and throw fatal errors only inside cron.

When the CLI path is not available or produces permission errors, fall back to the HTTP trigger using the installed curl or wget:

*/5 * * * * /usr/bin/curl -s "https://yourdomain.com/cron.php?dispatch=cron&cron_password=YOUR_KEY" >/dev/null 2>&1

In DirectAdmin Evolution the equivalent screen is Advanced Features → Cron Jobs. Fill the minute field with */5, leave hour, day, month, and weekday as *, and paste the same command body. DirectAdmin emails cron output by default to the account address, which is useful for a first run but noisy long term; keep the >/dev/null 2>&1 redirect once you have confirmed success, or set a dummy address in the panel's cron email field to suppress it.

Do not schedule the trigger more aggressively than every five minutes on shared hosting. Each invocation competes for your account's CPU and entry-process limits under CloudLinux LVE, and a one-minute cron on a busy store can push you into throttling, which paradoxically makes jobs run slower. Five minutes is granular enough for notifications and imports while staying inside typical resource caps.

Troubleshooting Stuck Imports, Queues, and Notifications

When background work stalls, verify the trigger is firing before you touch anything inside the application. Open Administration → Scheduler and look at the "Last run" and "Next run" columns for each task; a "Last run" timestamp that never advances means the external cron is not reaching cron.php at all. Test the URL manually in a browser with the correct password appended. A blank page or 0 is a healthy response. If you see an HTTP 500 or a fatal PHP message, the problem is PHP configuration rather than cron scheduling, and the same diagnostic flow used for other store errors applies, such as the approach in our guide to diagnosing white screens and HTTP 500s.

Imports deserve special attention because they are memory and time hungry. A large CSV product import launched from the admin panel runs in the foreground of a web request and is governed by max_execution_time and memory_limit, but when CS-Cart defers the import to the scheduler it runs under the CLI or cron context instead. Raise the ceilings for both contexts by placing a .user.ini in your store root:

memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 64M
post_max_size = 64M

Changes to .user.ini take effect after the user_ini.cache_ttl window, typically five minutes, so wait before retesting. For the CLI cron invocation specifically, you can also pass limits inline without touching any global file:

*/5 * * * * /opt/cpanel/ea-php82/root/usr/bin/php -d memory_limit=512M -d max_execution_time=0 /home/USERNAME/public_html/cron.php --dispatch=cron --cron_password=YOUR_KEY >/dev/null 2>&1

Email notifications that never leave the queue are usually a mail transport issue rather than a cron timing issue. Confirm the scheduler is running, then check Settings → Emails (or Administration → Notifications & Emails in newer releases) and set the sending method to SMTP pointed at your Hostiso mail host with authentication, instead of the PHP mail() function, which LiteSpeed and spam filters treat harshly. A mismatched From domain that fails SPF or DKIM will let CS-Cart mark messages as sent while the receiving server silently drops them.

For deeper evidence, read the logs inside your account. CS-Cart writes to var/log/ under the store root, and cron-specific failures often surface there with a timestamp matching your schedule. PHP fatal errors from the cron context land in the error_log file in the store root or in cPanel → Metrics → Errors. Open these in File Manager rather than guessing. A recurring "Allowed memory size exhausted" line points straight back to the limits above; a "could not connect" database line points to transient MySQL contention during large batch jobs, which you can soften by splitting imports into smaller files.

Keeping the Scheduler Healthy and Lean

Once cron fires cleanly, review which tasks the Scheduler actually runs so you are not burning resources on work the store does not need. In Administration → Scheduler you can disable individual tasks; on a catalog that never uses abandoned cart reminders or a storefront without recurring subscriptions, switching those off reduces each cron pass to the essentials of cache cleanup, sitemap, and notifications. Keep the cache and log cleanup tasks enabled, because an unpruned var/cache and var/log are a common cause of inode exhaustion and slow File Manager operations on shared accounts.

Guard the endpoint itself. Because cron.php accepts a password in the query string, it can leak into access logs and referrer headers. Rotate the cron password periodically from the admin panel, and resist the temptation to expose it in any client-side code. You can add a defensive rule in the store root .htaccess that blocks the endpoint from browsers while still allowing your own cron, though on LiteSpeed the cleanest protection is simply a long, random password plus never linking the URL anywhere public.

Finally, treat the cron job as something to monitor rather than set and forget. After every PHP version change in MultiPHP Manager or the PHP Selector, confirm the CLI binary path in your cron command still points to the matching version, because an upgraded account can leave the old ea-php path in place and send cron silently to a decommissioned interpreter. A weekly glance at the Scheduler "Last run" timestamps and the var/log directory will catch a stalled trigger long before customers notice missing order emails or a frozen import.