# Cron Jobs

> Schedule commands to run as the account user — WordPress cron, application tasks, backups and housekeeping — with resource limits and single-instance locking.

Source: https://www.corepanel.net/docs/accounts/cron-jobs/
Last updated: 2026-08-07
Part of the CorePanel documentation — https://www.corepanel.net/docs

---

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.

On **CorePanel Business**, the account owner manages their own jobs from the
[client panel](https://www.corepanel.net/docs/client-panel) — the same screen described below, with nothing taken
away. Jobs run as their user either way, and the per-account limit is the same number for
both of you.

## 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. |

> **`@reboot` and `@every` are not supported**
>
> Use a five-field spec instead — `*/30 * * * *` for "every 30 minutes".
### 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.

```bash
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](https://www.corepanel.net/docs/cli#cron-jobs) 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](https://www.corepanel.net/docs/wordpress) 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

```bash
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. |