| Schedule | Command | Description | Status | Actions |
|---|---|---|---|---|
0 5 * * * |
/usr/local/bin/custom-backup.sh >> /var/log/arciveo-cron.log 2>&1 |
Nightly backup to remote storage | ||
*/15 * * * * |
/usr/local/bin/healthcheck.sh |
Ping external uptime monitor |
| Command | |
|---|---|
30 1 * * * /usr/local/bin/clamav-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 2 * * * /usr/bin/aide --config /etc/aide/aide.conf --check > /var/log/aide/aide.log 2>&1 |
|
@reboot chmod 755 /var/lib/aide |
|
0 3 * * * /usr/local/bin/lynis-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 4 * * * /usr/local/bin/load-ipsum.sh >> /var/log/arciveo-cron.log 2>&1 |
|
@reboot sleep 60 && /usr/local/bin/load-ipsum.sh >> /var/log/arciveo-cron.log 2>&1 |
|
30 4 * * * /usr/local/bin/debsums-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 6 * * * /usr/local/bin/logwatch_daily.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 8 * * * /usr/local/bin/daily-report-all.sh >> /var/log/arciveo-cron.log 2>&1 |
|
*/30 * * * * /usr/local/bin/smart-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 * * * * /usr/bin/apt-get update -qq >/dev/null 2>&1 |
|
*/5 * * * * /usr/local/bin/collect-metrics-all.sh >> /var/log/arciveo-cron.log 2>&1 |
Cron tells you nothing. It does not report that a job failed, it does not show when one last ran, and a syntax error in the five schedule fields has nowhere to surface. Formally it mails the local user, but on a server where outbound mail was never configured that message is read by nobody. A job can sit broken for months, and it is the consequences that give it away.
This page lists the jobs added through the panel: schedule, command, description and state, with the option to enable, disable or remove one without opening a terminal. Below them, as a separate list, are the remaining lines of the root crontab, the ones you or an installed package put there earlier. Those are read-only: the panel deliberately does not edit what it did not write.
Three things are worth checking here. A job whose output goes to /dev/null 2>&1 is equally silent when it works and when it breaks. A command written as a bare name rather than a full path behaves differently than it does in your shell, because cron carries its own sparse PATH. And the schedule itself: a job switched off once for debugging usually stays off. Cron is also worth reading after any suspicion of a break-in, since persisting through the scheduler is easier than through a startup unit, and the line looks entirely ordinary.