Automating System Maintenance Tasks with Cron and Anacron

Backups, log clean-ups, certificate checks and update reports are jobs nobody should run by hand. On Linux you hand them to a scheduler: cron for exact times on a server that is always on, anacron for daily or weekly jobs that must still run after the machine was switched off, and systemd timers, which can do both. This guide shows how to use each one safely on a server you manage yourself.

1. Cron, anacron and systemd timers compared

On AlmaLinux and Rocky Linux, the cron service (cronie) already hands the jobs in /etc/cron.daily, cron.weekly and cron.monthly to anacron, so those folders catch up after downtime by default. On Debian and Ubuntu, anacron is a separate package, and many services now ship systemd timers instead of cron files.

2. Writing a cron job

Edit your own schedule with crontab -e. Each line is five time fields and a command:

# ┌ minute (0-59)
# │ ┌ hour (0-23)
# │ │ ┌ day of month (1-31)
# │ │ │ ┌ month (1-12)
# │ │ │ │ ┌ day of week (0-7, Sunday is 0 or 7)
# │ │ │ │ │
  30 2 * * * /home/deploy/bin/backup.sh >> /home/deploy/logs/backup.log 2>&1

That runs the backup at 02:30 every day and appends everything it prints, errors included, to a log file. Some patterns worth knowing:

*/15 * * * *   every 15 minutes
0 3 * * 0      03:00 every Sunday
0 9 1 * *      09:00 on the 1st of each month
@reboot        once, when the server starts

For a longer list of patterns, see the cron expression cheat sheet.

List your jobs with crontab -l. Be careful with crontab -r: it deletes every job for that user without asking. Keep a copy with crontab -l > ~/crontab.bak before big edits.

System-wide jobs go in a file under /etc/cron.d/, which takes an extra field for the user to run as:

# /etc/cron.d/certcheck
0 6 * * * root /usr/local/bin/check-certs.sh

3. Writing an anacron job

anacron doesn't use clock times. Each line in /etc/anacrontab says how often a job should run, how long to wait after anacron starts, a name, and the command:

# period(days)  delay(min)  job-id          command
1               10          db.dump         /usr/local/bin/db-dump.sh
7               20          logs.prune      /usr/local/bin/prune-logs.sh
@monthly        30          report.monthly  /usr/local/bin/monthly-report.sh

anacron records when each job last ran in /var/spool/anacron/. If the server was off when a job was due, the job runs after the next start, following its delay. On AlmaLinux and Rocky Linux, START_HOURS_RANGE and RANDOM_DELAY at the top of the file control when in the day catch-up jobs may run.

Useful commands, run as root:

anacron -T        # check /etc/anacrontab for syntax errors
anacron -f -n     # force every job to run now, ignoring timestamps

Often the simplest route is to drop an executable script into /etc/cron.daily/ and let the system's existing anacron setup run it. On Debian and Ubuntu, run-parts skips files whose names contain a dot, so name it db-dump, not db-dump.sh.

4. The systemd timer alternative

On current distributions, a systemd timer gives you cron-style schedules, anacron-style catch-up and logs in the journal. It takes two files:

# /etc/systemd/system/db-dump.service
[Unit]
Description=Nightly database dump

[Service]
Type=oneshot
ExecStart=/usr/local/bin/db-dump.sh

# /etc/systemd/system/db-dump.timer
[Unit]
Description=Run db-dump nightly

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=5min

[Install]
WantedBy=timers.target

Enable it with systemctl enable --now db-dump.timer, list all timers with systemctl list-timers, and read the output with journalctl -u db-dump.service. Persistent=true makes a run missed during downtime happen at the next boot.

5. Habits that make scheduled jobs reliable

Keep scripts that hold passwords readable only by their owner (chmod 700), and put secrets in a separate file with chmod 600 rather than in the crontab line itself.

6. Finding out why a job didn't run

1. Is the scheduler running? systemctl status crond on AlmaLinux and Rocky Linux, or systemctl status cron on Debian and Ubuntu.
2. Did it start? Read /var/log/cron on AlmaLinux and Rocky Linux, or journalctl -u cron on Debian and Ubuntu.
3. Did it fail? Read your job's own log file. "command not found" means a missing full path; "permission denied" means the script isn't executable (chmod +x).
4. Is the syntax right? Five time fields in a user crontab, six (with the user) in /etc/cron.d, and a newline at the end of the file.

7. Running scheduled jobs on Domain India

Shared hosting (cPanel and DirectAdmin). You add cron jobs from the control panel's Cron Jobs page, with no SSH needed. You can't use anacron, systemd timers or /etc/cron.d, because those are server-wide. Jobs run on Indian Standard Time. Jobs set to run every 1, 2 or 3 minutes are automatically changed to every 4 minutes, so 4 minutes is the shortest effective interval. The step-by-step guide is How to set up a cron job, and some PHP functions that scripts rely on are disabled on shared hosting; see PHP disabled functions.

VPS. A Domain India VPS is self-managed with full root access, so everything in this guide applies: crontabs, anacron, /etc/cron.d and systemd timers. The card shows the live price, excluding 18% GST.

Frequently asked questions

Ready to automate? Set up a job in your control panel with How to set up a cron job, compare VPS plans if you need root-level scheduling, or open a support ticket if a job on your hosting won't run.