Why Blesta Depends on a Single Cron Task

Blesta does almost nothing on a schedule by itself. The web interface only reacts to page loads, so every recurring action the billing platform performs is driven by an external cron job that calls a single automation script. When that cron runs, Blesta walks through a queue of tasks: generating recurring invoices, applying and capturing payments through your gateways, sending invoice and payment notices, processing service suspensions and terminations, running provisioning and email queues, and pruning logs. If the cron stops firing, none of this happens. Invoices never generate, cards never get charged, and overdue notices never leave the server, all while the admin dashboard looks perfectly healthy.

The task Blesta calls is located inside your account, typically at /home/USERNAME/public_html/index.php cron when Blesta is installed in the document root, or a deeper path such as /home/USERNAME/public_html/billing/index.php cron for a subdirectory install. Blesta expects this to be executed through the PHP command-line binary once per interval. Inside the admin area, under Settings > Automation, each individual task has its own frequency (for example, invoice creation daily, payment reminders daily, the provisioning queue every 5 minutes). The cron entry you place in cPanel or DirectAdmin does not set those frequencies. It simply pokes Blesta on a schedule, and Blesta decides internally which tasks are due. This distinction matters because two separate systems must agree: the OS-level cron cadence and the in-app automation settings.

The most common failure on shared hosting is that the cron was never added, was added with the wrong PHP path, or was added pointing at the browser URL instead of the CLI script. On LiteSpeed with CloudLinux, PHP versions are isolated per account, and the generic php binary a cron uses may be an old system default rather than the version your Blesta install actually runs on. That mismatch produces cron output that looks like a fatal error or nothing at all, which is why so many Blesta cron problems present as "it just silently stopped working."

Configuring the Cron Job in cPanel and DirectAdmin

Start by confirming the correct PHP binary for your account. On CloudLinux, the version-specific CLI binaries live under paths like /usr/local/bin/ea-php81, /usr/local/bin/ea-php82, or the selector alias /opt/alt/php82/usr/bin/php on DirectAdmin. Whichever PHP version you selected for the domain in MultiPHP Manager (cPanel) or PHP Version Selector (DirectAdmin) is the version your cron should use, so the CLI and the web requests behave identically. Using a matching version avoids situations where a Blesta extension loads fine in the browser but throws a missing-function fatal on the CLI.

In cPanel Jupiter, open Advanced > Cron Jobs. Set the schedule to run every five minutes, which satisfies Blesta's most frequent internal task, and enter the command. A typical entry looks like this:

*/5 * * * * /usr/local/bin/ea-php82 -q /home/USERNAME/public_html/index.php cron

In DirectAdmin Evolution, go to Advanced Features > Cron Jobs and use the same five-field schedule and command structure. Replace USERNAME with your actual account user and adjust the PHP path to the version you run. The -q flag suppresses HTTP-style header output that would otherwise be emailed to you on every run. If you prefer email only on real failures, leave the default and add a redirect later.

The trailing cron argument is mandatory. Without it, index.php loads the normal front-end bootstrap instead of the automation handler, so the job appears to "succeed" while doing no billing work. Avoid using a wget or curl call against a public URL such as https://yourdomain.com/index.php/cron. Blesta's cron is designed to run under the CLI SAPI, browser-triggered runs can time out on long queues, expose the endpoint, and hit LiteSpeed request limits. Keep it on the command line.

After saving, confirm the in-app side. Log into the Blesta admin, open Settings > Company > Automation, and verify the tasks you expect are enabled with sensible times. Blesta also shows the last time the cron completed. If that timestamp is recent after your next five-minute window, the pipeline is alive.

Troubleshooting Silent Failures and Wrong PHP Paths

When the cron is present but Blesta reports it never ran, capture the output. Temporarily append a log redirect to the command so you can read exactly what PHP returns:

*/5 * * * * /usr/local/bin/ea-php82 -q /home/USERNAME/public_html/index.php cron >> /home/USERNAME/cron_blesta.log 2>&1

The 2>&1 is important because it folds error output into the same file. Open cron_blesta.log through cPanel File Manager or DirectAdmin File Manager after a few cycles. A line like No such file or directory means the path to index.php is wrong, recheck the exact document root under File Manager. A message referencing an unknown PHP binary means the CLI path is invalid, list what exists by browsing to /usr/local/bin is not possible as an unprivileged user, so instead try alternate known paths (ea-php81, ea-php80) until one runs cleanly. A fatal about a missing extension such as mysqli or curl usually means the CLI PHP version differs from the web version, switch the cron to the exact ea-phpXX that matches MultiPHP Manager.

If the log stays empty on every run, the cron itself may not be executing. On some shared plans, the minimum interval is enforced, so a */1 schedule silently gets throttled; five minutes is safe. Also confirm the account is not over its process or resource limits, since CloudLinux LVE can kill a cron mid-run. You can review that under cPanel's Resource Usage statistics. A cron that dies from a memory ceiling on a large invoice batch benefits from a modest bump in .user.ini placed in the Blesta root:

memory_limit = 256M
max_execution_time = 300

Note that .user.ini primarily affects PHP under the web SAPI on LiteSpeed. CLI runs honor the account's PHP INI settings from PHP Selector in DirectAdmin or MultiPHP INI Editor in cPanel, so raise memory_limit there for the CLI to take effect. For deeper background on where account ceilings actually bite before you consider upgrading, see MantisBT Resource Limits on Shared Hosting, the same LVE diagnosis approach applies to Blesta's batch jobs.

Finally, review Blesta's own logs. Under Tools > Logs > Cron, each task run is recorded with success or error detail, this is often more descriptive than the shell output because it reflects gateway responses and module errors. If invoices generate but payments fail, the problem is a gateway task, not the cron, and the fix lives in Billing > Payment Gateways rather than in your cron entry. Once everything runs cleanly for a day, remove the temporary log redirect so you are not writing growing files into your account.