This guide covers everything about managing scheduled tasks in Panelica --- from creating your first cron job to monitoring system-level scheduled tasks and using the template library.
Panelica has two separate cron job systems:
- Domain Cron Jobs --- Tasks that run in the context of a domain's system user. Available to all roles. Managed from Domain Edit or the System Tools page.
- System Cron Jobs --- Server-level tasks that run as root or any system user. Available to ROOT and ADMIN only. Managed from System Tools.
---
There are three ways to manage cron jobs:
- Domain Edit > General Tab --- Go to Domains > click Edit > scroll to the Cron Jobs section. Shows cron jobs for that specific domain with a usage counter (e.g., "3/5 cron jobs used").
- System Tools > Cron Jobs --- Go to System Tools > Cron Jobs. Shows all cron jobs across all domains with three tabs: Domain Cron Jobs, System Cron Jobs, and Templates.
- System Tools > Cron Jobs > System Tab --- ROOT/ADMIN only. Server-level cron jobs with statistics dashboard.
---
Step 1: Go to Domain Edit > General tab > Cron Jobs section, or System Tools > Cron Jobs.
Step 2: Click Add Cron Job. A modal opens with the template library.
Step 3: Choose a template or select Custom Script:
- Template categories: Laravel Artisan, WordPress, Framework-specific, Database maintenance, SSL automation, Backup automation, Security, Monitoring, and more
- Selecting a template auto-fills the schedule, timeout, and command
Step 4: Fill in the form fields:
| Field | Required | Description |
|---|---|---|
| Task Name | Yes | A display name for the job (max 255 chars) |
| Command | Yes | The shell command to execute (max 10,000 chars) |
| Schedule | Yes | 5-field cron format (minute, hour, day, month, weekday) |
| Timeout | No | Maximum execution time in seconds (1--3600, default: 3600) |
| Email on Error | No | Send email notification when the job fails |
| Email Recipient | Conditional | Required if Email on Error is enabled |
Step 5: Click Save. The job is created and enabled by default.
---
Panelica uses standard 5-field cron format:
Code:
+------- minute (0-59)
| +------- hour (0-23)
| | +------- day of month (1-31)
| | | +------- month (1-12)
| | | | +------- day of week (0-7, 0 and 7 = Sunday)
| | | | |
* * * * *Common Schedule Examples:
| Schedule | Format | Runs |
|---|---|---|
| Every minute | * * * * * | 60 times/hour |
| Every 5 minutes | */5 * * * * | 12 times/hour |
| Every 30 minutes | */30 * * * * | 2 times/hour |
| Every hour at :00 | 0 * * * * | 24 times/day |
| Daily at 2 AM | 0 2 * * * | Once per day |
| Daily at noon | 0 12 * * * | Once per day |
| Weekly (Sunday midnight) | 0 0 * * 0 | Once per week |
| Monthly (1st day) | 0 0 1 * * | Once per month |
| Weekdays at 9 AM | 0 9 * * 1-5 | 5 times per week |
The form includes a Basic mode with preset schedules (every minute, hourly, daily, weekly, monthly) and an Advanced mode for custom cron expressions. A live preview shows the next execution time in human-readable format.
---
The template library includes 60+ pre-configured templates organized by category:
Backup & Database
- MySQL dump (daily at 2 AM)
- PostgreSQL backup
- Files backup (rsync)
Laravel Artisan
- Cache clear
- Queue processing
- Schedule runner (every minute)
- Migrate database
- Storage link
WordPress
- Plugin update check
- Database optimization
- Backup database
- Clean logs
- SSL certificate check
Security
- SSL certificate renewal (Let's Encrypt)
- Log rotation
- Firewall rules update
Monitoring
- Uptime check
- Health check endpoint
- Disk space check
When you select a template, the schedule, timeout, and command are auto-populated. Templates may include placeholders like
{{domain}} that are resolved at creation time.ROOT and ADMIN users can also create custom templates from System Tools > Cron Jobs > Templates tab.
---
Each cron job supports these actions:
1. Enable/Disable
Toggle a job on or off without deleting it. Disabled jobs skip execution but retain their schedule.
2. Edit
Modify the task name, command, schedule, timeout, or email settings.
3. Execute Now
Manually trigger immediate execution. The system:
- Acquires a lock to prevent duplicate runs
- Executes the command with the configured timeout
- Captures stdout and stderr output
- Records exit code and duration
- Creates an execution log entry
4. View Execution Logs
Opens a modal showing the last 20 executions with status, exit code, duration, and output.
5. Clear Logs
Removes all execution history for the job.
6. Delete
Permanently removes the cron job.
---
From the System Tools > Cron Jobs page, you can select multiple jobs and perform bulk actions:
- Bulk Enable --- Enable all selected jobs
- Bulk Disable --- Disable all selected jobs
- Bulk Execute --- Run all selected jobs immediately
- Bulk Delete --- Delete all selected jobs (with confirmation)
- Bulk Clear Logs --- Clear execution history for all selected jobs
- Bulk Stop --- Stop all currently running selected jobs (sends SIGTERM)
---
Every execution is recorded with detailed information:
| Field | Description |
|---|---|
| Executed At | When the job started |
| Status | Success (green), Error (red), Timeout (yellow), Killed (gray) |
| Exit Code | Shell exit code (0 = success) |
| Duration | How long the job ran |
| Stdout | Command output (expandable) |
| Stderr | Error output (expandable) |
| Triggered By | "Scheduled" or the username who ran it manually |
You can also view Running Jobs (currently executing) and Jobs with Errors (recent failures) from dedicated sections.
Stopping a Running Job: Click the Stop button to send SIGTERM to the running process. The status changes to "killed".
---
System cron jobs run at the server level and have additional features:
Extra fields:
- Run As User --- Which system user to execute as (default: root)
- Description --- Extended documentation for the job
- Priority --- Execution priority from 1 (highest) to 10 (lowest)
- Timeout --- Up to 7200 seconds (2 hours) for system jobs
Statistics Dashboard:
The System Cron Jobs tab includes a statistics card showing:
- Total jobs / Enabled / Disabled / Running
- Total executions / Success count / Failure count
- Success rate percentage
- Executions in last 24 hours
Each system job also tracks lifetime statistics: total runs, success count, failure count, and average duration.
---
The number of domain cron jobs per user is controlled by the max_cron_jobs setting in their service plan:
- -1 = Unlimited cron jobs
- 0+ = Specific limit
The Domain Edit page shows a usage counter (e.g., "3/5 cron jobs used"). When the limit is reached, creating new jobs returns an error.
---
Cron job commands run with several security measures:
- User isolation: Commands execute as the domain owner's system user, not root
- Cgroup limits: CPU, memory, I/O, and process count are limited by the user's plan
- Path restrictions: Commands run within the domain owner's home directory context
- Command validation: Dangerous commands (direct database access, permission elevation) are blocked
- Concurrent lock: Prevents the same job from running simultaneously
PHP scripts should use the full PHP path:
/opt/panelica/services/php/8.4/bin/php /home/username/domain.com/artisan schedule:runYou can validate a command before saving using the Validate Command endpoint, which returns errors and warnings.
---
Problem: Job shows "Error" status
- Check the execution logs for the exit code and stderr output
- Common causes: command not found, permission denied, script error
- Verify the command works when run manually via Terminal
Problem: Job shows "Timeout" status
- The job exceeded its timeout limit
- Increase the timeout value (max 3600 for domain jobs, 7200 for system jobs)
- Optimize the script to run faster
Problem: "Limit reached" error
- Your service plan's max_cron_jobs limit has been reached
- Delete unused cron jobs or ask your admin to increase the plan limit
Problem: Job not running on schedule
- Check that the job is enabled (green toggle)
- Verify the cron schedule format is correct
- Check if another instance is already running (locked)
- Review the scheduler logs at
/opt/panelica/var/logs/backend/backend.log
---
- Use templates when possible --- They include recommended schedules and timeouts
- Set appropriate timeouts --- Don't leave the default 3600s for quick tasks
- Enable email notifications --- Get alerted when critical jobs fail
- Monitor execution logs --- Check the "Jobs with Errors" section regularly
- Avoid overlapping schedules --- If a job takes 10 minutes, don't schedule it every 5 minutes
- Use full paths --- Always use absolute paths for PHP, Python, and other interpreters
- Test commands first --- Run the command manually via Terminal before scheduling
- Clean up old logs --- Use Clear Logs periodically to keep the database lean