Cron jobs

The Cron jobs section of a server (/servers/:id/cron) manages the scheduled tasks on that box. MZPanel gives its own jobs a full lifecycle — create, run, pause, edit, delete, and per-run logs — while showing the machine’s existing system cron read-only so nothing is hidden from you. It’s available on all plans.

Create a job, step by step

1. Click New job to open the create drawer.
2. Enter a Name, the Command to run, and pick the Run as user (populated from the box’s real system users).
3. Set the Schedule: pick a preset (every minute, hourly, daily at 03:00, weekly, @reboot, …) or type a raw cron expression — a colour-coded five-field breakdown shows exactly when it will fire. Prefer to paste? Switch to paste full line and drop in a whole crontab line; MZPanel splits it into the fields for you.
4. Save. The job appears in the list with a live countdown to its next run.

What else you can do

The page is a searchable list of job cards, each showing status, name, schedule, command, run-as user, last run, and a live next run countdown.

• Filter and search — by status (All / Active / Failing / Paused) or type (Sites, MZPanel, System), and search across name, command, schedule and user.
• Run now — trigger a job immediately; its output streams live in a drawer, ending with the exit code.
• View logs — open the run history: newest-first records, each expandable to show exit code, duration and captured output.
• Pause / resume, edit, and delete a panel-created job.

How it works

Actions on this page dispatch cron.* jobs to the server’s agent, which runs them natively:

Action	Job	Agent runs
List	cron.list	cron list --json
Create	cron.add	writes /etc/cron.d/mz-custom-<slug>
Edit	cron.update	rewrites the managed file
Pause / resume	cron.toggle	enable/disable the entry
Delete	cron.remove	removes the managed file
Run now	cron.run	runs once, streaming stdout/stderr
View logs	cron.logs	reads the run-log ring buffer

Panel-created jobs live in their own files under /etc/cron.d/mz-custom-*, so they never touch the machine’s existing cron. Scheduled runs go through a small run-logger that keeps the last 25 runs of each job — timestamp, exit code, duration and an output tail — under /var/log/mzcron/. That’s what View logs reads.

CLI & automation

Every action here maps to an mz command on the box — the same engine the dashboard drives. SSH in and run them directly, or let an on-box AI (ClaudeCode) run them:

mz cron list --json                       # list jobs
mz cron add --schedule "0 3 * * *" \
   --command "wp cron event run --due-now --path=/var/www/site" --user www-data
mz cron run <id>                          # run once, streams output
mz cron log <id> --json                   # a job's run history

Always pass a sub-action (mz cron alone errors) and --json for machine output. See The mz CLI and the command catalog.

Gotchas & troubleshooting

• System / non-MZPanel cron is read-only. On a live server, only MZPanel-managed jobs can be edited, paused, run or deleted; existing system/package cron is shown for visibility but never rewritten. System jobs are hidden by default — pick the System type filter to see them.
• “Run now” isn’t written to the log. A manual run streams its output live but is intentionally not added to the run-log — the log records the scheduled runs. Use Run now to test, View logs to audit the schedule.
• Offline servers show cached cron. The list renders from the last known state; creating, running, or viewing live logs needs the agent online.
• WordPress sites don’t need per-site cron. A single box-wide dispatcher runs every minute and fans out to every WP site on a stagger, so you won’t (and shouldn’t) create a wp-cron entry per site here.

Related

• Monitor a server — services, OS updates, storage.
• The mz CLI — driving the box from the command line.