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.

What is cron (and why it’s famous)

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.

The new way: understanding systemd timers

Systemd timers are a more modern approach to scheduling. Instead of one file, they use two:

  1. A .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.
  2. A .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.

Key advantages of systemd timers

Systemd timers aren't just a replacement for cron; they offer a lot more scheduling options.

  • Event-Based Triggers: Timers can start jobs based on events, not just time. You can trigger a task "15 minutes after boot" (OnBootSec=), "1 hour after the last time it ran" (OnUnitActiveSec=), or when specific hardware is plugged in.
  • Dependency Management: This is a big one. You can tell your timer to run a job only after another service is active. For example, you can make your backup script wait until the network connection (network.target) and your database service are both fully online.
  • Integrated Logging: All output (STDOUT and STDERR) from your job is automatically captured by the 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.
  • Missed Job Handling: What happens if your server is off at 2:30 AM when the cron backup was supposed to run? Cron just skips it. Systemd can fix this. By setting Persistent=true in your timer file, systemd will run the job as soon as the server boots up if the scheduled time was missed.
  • Resource Control: Because each job is a standard systemd service, you can use all of systemd's resource management features (cgroups) to limit the CPU, memory, or I/O your scheduled task is allowed to use.

You can find extensive details in the official systemd.timer documentation.

When to use cron vs. systemd timers

So, which one should you choose?

You should stick with cron if:

  • You need your script to be portable to non-systemd environments (like BSD or older Linux distros).
  • Your task is extremely simple (e.g., "run this one command every hour") and you value the speed of crontab -e.
  • You are on a multi-user system and prefer the simple crontab permission model for each user.

You should move to systemd timers if:

  • You need your job to run after boot or relative to other services (like the network).
  • You need to run a job that was missed while the server was offline.
  • You want much better, centralized logging for your task's output.
  • You need to run a task on a complex schedule (e.g., "every 15 minutes, but only during business hours").
  • You need to control the resources (CPU/memory) your job consumes.

On a modern systemd-based server, systemd timers are generally the preferred method for any serious automation.

How to create a systemd timer (a simple guide)

Let's convert that 2:30 AM backup script from cron to a systemd timer.

Step 1: Create the .service file

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.

Step 2: Create the .timer file

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.

Step 3: Enable and start the timer

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

Frequently asked questions

Is cron deprecated?

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.

Can I use cron and systemd timers on the same server?

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.

How do systemd timers handle missed jobs?

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).

How do I see the output or logs from my systemd job?

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.

Conclusion

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.