Systemd Timers vs. Cron: Which One Should You Use?
Choosing between systemd and cron for scheduled tasks? We explain the key differences, benefits, and when to use each for your Linux server.
Publish date: 12/3/2025
Choosing between systemd and cron for scheduled tasks? We explain the key differences, benefits, and when to use each for your Linux server.
Publish date: 12/3/2025
If you've ever managed a Linux server, you've needed to run a script on a schedule. For decades, the go-to tool for this has been cron, the simple and reliable time-based job scheduler.
But on most modern Linux distributions, there's another major player: systemd.
While systemd is known as an init system (the first process that starts after the kernel), it also includes its own scheduling system called timers. This has sparked a common debate among system administrators: should you stick with the classic crontab, or is it time to move to systemd timers?
Let's break down the differences and help you decide which one is right for your task.
Cron is the classic Linux task scheduler. It's driven by a configuration file known as a crontab, which is basically a list of jobs and the times they should run.
The syntax is famous for its five-asterisk format, which represents minute, hour, day of the month, month, and day of the week.
# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of week (0 - 6) (Sunday=0)
# │ │ │ │ │
# * * * * * /path/to/your/script.sh
For example, to run a backup script at 2:30 AM every day, you would add this line to your crontab:
30 2 * * * /opt/scripts/backup.sh
The main benefit of cron is its simplicity. It's straightforward, pre-installed almost everywhere (including non-systemd systems like BSD), and has a huge amount of documentation. If you need a simple script to run at a specific time, cron is a fantastic, no-fuss solution. You can edit your user's crontab with crontab -e. For a great tool to help build cron schedules, check out crontab.guru.
Systemd timers are a more modern approach to scheduling. Instead of one file, they use two:
.service file: This file defines what job to run. It's the exact same kind of service file you'd use to manage a long-running process like a web server, but for a one-off task..timer file: This file defines when to run the service. It controls the schedule.This separation of "what" from "when" is the first clue to systemd's flexibility.
Systemd timers aren't just a replacement for cron; they offer a lot more scheduling options.
OnBootSec=), "1 hour after the last time it ran" (OnUnitActiveSec=), or when specific hardware is plugged in.network.target) and your database service are both fully online.journald logging service. You can easily check the full history and output of your job by running journalctl -u mytask.service. This is much cleaner than cron's default behavior of emailing output.Persistent=true in your timer file, systemd will run the job as soon as the server boots up if the scheduled time was missed.You can find extensive details in the official systemd.timer documentation.
So, which one should you choose?
You should stick with cron if:
crontab -e.crontab permission model for each user.You should move to systemd timers if:
On a modern systemd-based server, systemd timers are generally the preferred method for any serious automation.
Let's convert that 2:30 AM backup script from cron to a systemd timer.
First, define the job. Create a file at /etc/systemd/system/backup.service:
[Unit]
Description=Run my daily backup script
# Add dependencies here if needed, e.g., Requires=network-online.target
# After=network-online.target
[Service]
Type=oneshot
ExecStart=/opt/scripts/backup.sh
The Type=oneshot tells systemd this is a script that runs once and then exits, not a continuous service.
Next, create the schedule. Create a file at /etc/systemd/system/backup.timer (note it has the same name as the service file):
[Unit]
Description=Run daily backup script at 2:30 AM
[Timer]
OnCalendar=daily
AccuracySec=1m
Persistent=true
[Install]
WantedBy=timers.target
OnCalendar=daily is a shortcut for *-*-* 00:00:00. We can be more specific, just like cron. To match our 2:30 AM schedule, we'd use OnCalendar=*-*-* 02:30:00.Persistent=true is the magic setting that runs the job on boot if the server was off at 2:30 AM.[Install] tells systemd to automatically start this timer on boot.You're done creating the files. Now just tell systemd to load them and start the timer (not the service).
# Reload systemd to read the new files
sudo systemctl daemon-reload
# Enable the timer to start on boot
sudo systemctl enable backup.timer
# Start the timer right now
sudo systemctl start backup.timer
That's it! Your timer is now active. You can check its status and when it's scheduled to run next with:
systemctl list-timers
No, not at all. Cron is still included in almost every Linux distribution and is perfectly fine to use. Many system packages still rely on it. However, for your own new system-level tasks on a server running systemd, timers are often a better fit.
Absolutely. They are completely separate systems and don't interfere with each other. You can use cron for simple user-level scripts and systemd for more complex system-wide tasks.
As mentioned, you just need to add Persistent=true to the [Timer] section of your .timer file. If the system is powered on and systemd sees that a scheduled run time was missed, it will trigger the job immediately (or after RandomizedDelaySec if you've set that).
It's easy! All output is sent to journalctl. Just use the name of your service file (not the timer file):
journalctl -u backup.service
You can add -f to follow the logs live, or -n 100 to see the last 100 lines.
For Linux sysadmins and developers, cron is an old friend: simple, predictable, and reliable for basic time-based tasks. It's not going anywhere.
But for any scheduling that requires dependencies, better logging, or guarantees about running missed jobs, systemd timers are the modern, more capable solution. Learning to use them is a great way to better manage automation on your servers.
Thanks for reading! If you're looking for reliable infrastructure, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any workload. We also offer IP transit, shared hosting, and other IT services.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.