PanelicaDocs
panelica.com
Docs / Tools & Settings / Cron Jobs

Cron Jobs

Panelica 1.0.375 Verified 2026-07-24 Tools & Settings

Cron Jobs runs scheduled tasks: a WordPress cron every minute, a nightly database backup, a weekly log cleanup. It manages both domain jobs (a customer's scheduled command) and system jobs (server-wide, admin-only), with a visual scheduler, ready-made templates, per-run logs, and command validation that stops a customer job from escalating to root.

Panel locationTools → Cron Jobshttps://YOUR-SERVER-IP:8443/tools/cron
 Cron Jobs
Domain Jobs System Jobs Templates All Logs
TaskScheduleNext runActions
WordPress CronEvery 5 minutesin 3m 12srun · logs · edit · delete

The four tabs

Domain Jobs are scheduled commands attached to a domain, running as that domain's user. System Jobs (ROOT/ADMIN) run server-wide as a chosen system or panel user. Templates offers ready-made jobs to start from. All Logs is a searchable history of every execution. Four cards up top track domain and system job counts, the success rate and the last 24 hours' executions with any failures flagged.

Creating a job

The dialog covers: the domain (and optional subdomain) for a domain job, with an "insert path" helper that fills in the document root; a task name; the command; the schedule (below); a timeout; an email-on-error option; and, for system jobs, the run-as user, a priority and a description.

The schedule has two modes. Simple is a dropdown of presets, every minute, every 5/15 minutes, hourly, every 2 hours, daily at midnight/2am/3am, weekly, monthly. Advanced gives you the five cron fields (minute, hour, day, month, weekday) to type ranges and steps directly. A schedule-reference card at the bottom lists common cron expressions. Each job's row shows a live countdown to its next run.

Behind the scenes: jobs are stored in the database (not a crontab file) and run by Panelica's own scheduler daemon, which survives a backend crash and uses a database lock so a job never double-runs. A domain job executes through an isolation wrapper that drops it into the owner's namespace, chroot and cgroup, exactly the same isolation as an SSH session, so a customer's cron cannot see or touch another account. Each run records its output, exit code and duration.

Templates

Nearly thirty ready-made templates, grouped by category: CMS (WordPress cron, Laravel scheduler), monitoring (site health, response time, error-log summary, disk alerts), cleanup (clear PHP sessions and temp files, compress old logs, purge binlogs, rotate nginx logs), backup (domain and panel database backups), service (status checks and restarts), cache (flush Redis), and security (SSL-expiry check, ClamAV database update and scans). Click Use and the template fills the create dialog; for a domain template, placeholders like {DOMAIN} and {PUBLIC_HTML} are replaced with the real values once you pick the domain.

Managing jobs

Each row offers Run now, View logs, Edit, an enable/disable toggle and Delete. Jobs that failed repeatedly (three or more times in 24 hours) are highlighted. Select several rows for bulk run / enable / disable / clear-logs / delete. The log view shows each run's status, timing, exit code, trigger (manual or scheduled), and full stdout/stderr. The All Logs tab filters the whole history by success or failure.

Behind the scenes, the privilege-escalation guardrail: a customer's domain command is validated before it is saved. Path traversal and access to another user's home are refused; a blocklist stops dangerous commands (rm -rf /, mkfs, fork bombs, sudo/su, systemctl, shell-injection patterns like $(...) and pipe-to-shell); and for plain USER accounts a whitelist limits commands to safe interpreters (PHP, Python, Node, curl, wp, composer, git and the like). The command is also syntax-checked with bash -n without running it. System jobs skip this (they are admin-only and meant to run privileged commands).
Email-on-error is collected but not yet sent. You can set an error-notification address on a job, and it is saved, but the email delivery for it is not implemented in this version, so do not rely on getting an email when a cron fails. Use the logs and the failure highlighting on the page to catch failing jobs instead.

Access

Behind the cron_jobs license feature, with granular per-action permissions and the roles and permissions chain scoping which jobs each account sees. The Templates tab and system jobs are hidden from plain USERs; system-job management requires ROOT or ADMIN.

Panelica Documentation · Written and verified against the live panel. · Last verified 2026-07-24 on Panelica 1.0.375