Cron Jobs

Cron jobs let an account run a command on a schedule: WordPress’s cron entry point, a Laravel scheduler, a nightly database dump, a cleanup script. CorePanel stores the jobs and renders the account’s crontab, which cronie executes as the account’s user.

That last part matters: jobs keep running whether or not the panel is up, and they behave exactly as they would on a cPanel server.

Adding a job

Open Cron jobs, select the account, and click Add job. You provide:

Field	Notes
Schedule	A five-field cron spec (`/5 * * *`) or a macro (`@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`). Validated before it is stored, and the next run is computed straight away.
Command	One shell line, run as the account user.
Comment	A label so the list is readable six months later.
Email output to	Where to send the job’s output. Leave empty to send none.
Timezone	An IANA timezone (`America/Santiago`) if the schedule should not follow the server’s.
Enabled	A disabled job stays in the list, commented out of the crontab.

Resource limits per job

Each job can carry its own guard rails, which is what keeps one runaway task from taking the server down:

Option	Effect
Single instance	Skip the run if the previous one is still going (`flock`). The fix for a slow job scheduled every minute.
Timeout	Kill the job after N seconds.
CPU seconds	Cap CPU time.
Memory (KB)	Applied to PHP jobs as PHP’s own `memory_limit`.
Max processes	Cap how many processes the job may spawn.
Nice	0–19; higher means it yields to everything else.

An account may define up to 100 jobs.

Running a job now

Run now executes the job immediately and shows its output and exit code — the fastest way to find out whether a command works before waiting for its schedule. The list also shows each job’s last run and last exit code.

Writing the command

The command is a normal shell line, run as /bin/sh -c '<your command>' with the account user’s privileges. Two things trip people up most often:

php resolves to the account’s own PHP version. Write php ~/public_html/cron.php, never /usr/bin/php — there is no global PHP on a CorePanel host, and hardcoding a path pins the job to one version and loses the temporary-directory isolation and the memory limit.
It is sh, not bash. For [[ ]], arrays or process substitution, wrap the line: bash -c '...'.

wp (WP-CLI), curl, git, tar, rsync, jq and the MariaDB client are on the PATH. % needs no escaping — CorePanel escapes it for cron.

php ~/public_html/cron.php
wp --path="$HOME/public_html" cron event run --due-now
curl -fsS https://example.com/tasks/run > /dev/null
mysqldump --defaults-extra-file="$HOME/.my.cnf" mydb | gzip > ~/backups/db-$(date +%F).sql.gz

The CLI reference documents the command environment in full — available tools, ~ expansion, what does not work and why.

WordPress and cron

WordPress’s built-in cron only fires when somebody visits the site, which makes scheduled posts and updates unreliable on a quiet site. Installing WordPress through the WordPress Manager replaces it: DISABLE_WP_CRON is set in wp-config.php and a real cron job runs the queue every five minutes.

From the CLI

corepanel cron list 12
corepanel cron add 12 --schedule "*/5 * * * *" --command "php ~/public_html/cron.php"
corepanel cron run 12 3
corepanel cron disable 12 3

Troubleshooting

Symptom	Usual cause
Exit code `127`	Command not found — most often `/usr/bin/php`. Use `php`.
Nothing seems to run	The job is disabled, or the schedule is not what you think. Use Run now to test the command itself.
Overlapping runs pile up	Enable single instance.
No output arrives	No address in Email output to — a job with no recipient sends nothing.
Permission denied	Jobs run as the account user, never as root, and cannot read other accounts’ files.