cron vs systemd timers: Automate Your Linux VPS

A VPS is a server running continuously, often without direct human supervision. That is precisely why automating recurring tasks is essential: nobody will be around at 3 AM to trigger a backup or renew a Let's Encrypt certificate. A forgotten task can mean data loss, an expired certificate taking the site offline, or a disk full because log rotation never ran.

In practice, five categories of tasks come up on every serious Linux VPS: Nginx log rotation (logrotate or a dedicated script) to prevent /var/log/nginx/ from growing into gigabytes over a few weeks; orphaned Docker image cleanup (docker image prune -af) to reclaim disk space without manual intervention; PostgreSQL backups (pg_dump to remote storage) to guarantee an acceptable RPO in case of failure; SSL certificate checking before expiry, to trigger a certbot renewal rather than discover a broken HTTPS site; and scheduled lightweight scraping or indexing scripts that need to run at a fixed time. The two main tools available on Linux — cron and systemd timers — allow you to schedule these operations reliably.

Cron is present on virtually every Linux system. To schedule a task, edit the current user's crontab with crontab -e. The syntax uses five fields separated by spaces, followed by the command:

# ┌── minute (0-59)
# │  ┌── hour (0-23)
# │  │  ┌── day of month (1-31)
# │  │  │  ┌── month (1-12)
# │  │  │  │  ┌── day of week (0-7, 0=Sunday)
# │  │  │  │  │
  0  3  *  *  *  /usr/local/bin/backup.sh

Shortcuts @daily, @weekly, @monthly and @reboot simplify common cases. Files placed in /etc/cron.d/ belong to the system and can specify the execution user directly on the line. To review past executions, two paths: /var/log/syslog (Debian/Ubuntu) filtered with grep CRON /var/log/syslog, or journalctl -t CRON on systems with journald. One often-underestimated detail: cron's default PATH is minimal — /usr/bin:/bin — which forces the use of absolute paths in scripts, or redefining PATH= at the top of the crontab. The MAILTO variable controls output mailing; setting it to empty (MAILTO="") silently disables it. Cron keeps no native history of past runs and does not handle missed jobs if the machine was off.

A systemd timer is a pair of two unit files: a .service file describing what to run, and a .timer file describing when to trigger it. The timer is activated with systemctl enable --now myservice.timer and managed by the service manager, exactly like any other systemd service.

The OnCalendar= directive accepts rich, readable syntax:
- daily — every day at midnight
- Mon *-*-* 03:00:00 — every Monday at 3 AM
- *-*-* 02:30:00 — every day at 2:30 AM
- *:0/15 — every 15 minutes

The AccuracySec= directive (default: 1 minute) lets systemd group nearby timers to save CPU wakeups — on a shared or low-power server, reducing this to 1s ensures precise trigger times. The Persistent=true directive in the [Timer] block is the feature that sets systemd timers apart from cron: if the machine was off at the scheduled time, the timer catches up the missed execution at next boot. All output goes through journald and is accessible via journalctl -u myservice.service. The command systemctl list-timers shows all active timers, their next deadline and last activation date.

Cron remains the right choice in several concrete situations. On older or minimal systems without systemd — some lightweight Docker containers, Alpine images, BSD systems — cron is often the only tool available and there is no reason to move away from it. In a multi-user environment where each developer manages their own tasks via crontab -e without root rights, cron is simpler to delegate: creating a systemd .service requires access to /etc/systemd/system/.

For simple one-liner scripts — a weekly certbot renew, a nightly rsync with no dependencies — the crontab stays readable and maintainable without multiplying files. Cron is also the right choice for onboarding a non-Linux team: the five-field syntax, documented everywhere, is more accessible than a systemd unit for someone new to system administration. Finally, if your cron tasks have been working for years without issues, migration brings no immediate value. The deciding criterion is the need for structured logs, inter-service dependencies, or resource constraints — if you don't need them, cron does the job.

Systemd timers become the clear choice as soon as the task goes beyond a simple isolated command. You need journald to trace every execution, its output and return code without manual plumbing? Systemd timers. Your backup script must only run after PostgreSQL is ready, declaring After=postgresql.service in the [Unit] block? Systemd timers. You want to cap the memory of a sync job so it does not starve other processes (MemoryMax=512M)? Systemd timers.

Inter-service dependencies are the strongest argument: a backup launched while the database is not yet available after a reboot produces an empty file with no visible error under cron. Systemd guarantees the order. Integrated logging via journald removes all the noise from manual redirections — journalctl -u backup.service --since yesterday gives the full history with return codes. Error handling with OnFailure= lets you trigger a notification (email, webhook) without polluting the script itself. And if the server restarts at 2:58 AM when the 3 AM backup was due, Persistent=true guarantees it will run at next boot — something cron cannot do without anacron.

Five problems come up regularly when setting up timers.

1. "Unit not found" on systemctl enable — the .timer or .service file is not in /etc/systemd/system/ or has an incorrect name. Check the exact spelling with ls /etc/systemd/system/*.timer. A daemon-reload is mandatory before any enable or start on a new file.

2. Timer active but never triggers — does systemctl list-timers show a coherent date in the NEXT column? If NEXT is empty or in the past, a missing Persistent=true combined with a machine that hasn't rebooted since the timer was created is a common cause. Check systemctl status backup.timer: active (waiting) is the normal state.

3. ExecStart not found or permission denied — the PATH in a .service is minimal like cron. Always use the absolute path in ExecStart= (/usr/bin/certbot not certbot). Verify the script is executable (chmod +x /usr/local/bin/backup.sh) and that the user declared in User= has access to it.

4. Permissions on the script — if User=postgres but the script is owned by root without execute permission for postgres, the service will fail with code 203/EXEC. Check journalctl -u backup.service -n 20 to see the exact message.

5. Conflict between cron and systemd on the same task — if you are migrating progressively, make sure both are not active simultaneously for a destructive task (log purge, file rotation). Both will execute independently and double the operations. The check is simple: crontab -l | grep backup and systemctl is-active backup.timer.

Cron and systemd timers coexist without issue on the same server — you do not have to migrate everything at once. Keep cron for your simple tasks and existing user scripts, and adopt systemd timers for new automations that benefit from journald logs, inter-service dependencies or cgroup isolation. The systemd-analyze calendar command and systemctl list-timers are your best allies for validating and monitoring your schedules.