What systemd Is and What Timers Are (the Modern Alternative to cron)

A Linux server is never really idle: behind the scenes, dozens of programs start at boot, sit listening, and get restarted if something goes wrong. Something has to coordinate all of this, decide what to start and in what order, and decide what to do when a program stops working. On most modern Linux systems that “something” is called systemd. Understanding what it is, and what its timers are, helps you reason about how a Linux machine runs its services and schedules recurring tasks.

What systemd is

The official documentation defines it plainly: systemd is “a system and service manager for Linux operating systems.” In practice it’s the first program that starts when the machine powers on, technically process number 1 (or PID 1), and from there it starts and keeps alive all the others. It’s what’s called an init system: the ancestor from which every other process on the system descends.

A word on what “service” means here. A service (or daemon) is a program that runs in the background without an interface you interact with directly: the web server that answers page requests, the database, the system that sends email. You don’t “open” it like an app; it starts on its own and stays running. systemd’s job is to start these programs in the right order, keep an eye on them, and restart them when needed.

systemd is used by most of the widely adopted Linux distributions, which is why it’s worth knowing even in broad strokes: it’s the starting point for understanding how a Linux machine behaves at boot and while it’s running.

Units: the building blocks of systemd

Everything systemd manages is described by a unit. A unit is simply a text file that describes an object of the system and how to handle it. The documentation lists eleven different types; the most common ones are enough to get the idea:

.service units start and control services (the daemons above);
.socket units handle network or local connections;
.mount units take care of disk mount points;
.target units group other units or mark well-known milestones in the boot process (for example, “the system is ready for the network”);
.timer units, the subject of this article, trigger the activation of other units based on time.

The advantage of this scheme is uniformity. Whether it’s a disk, a service, or a scheduled task, the logic is always the same: a file that describes the object, and a single set of commands to manage it.

What timers are

Here’s the key point, spelled out calmly. A systemd timer doesn’t run a command: it starts another unit at a given moment. By convention a timer activates the service with the same name (backup.timer starts backup.service), and the real work, the command to run, lives in that service. The timer only says when.

Timers come in two families.

Calendar timers fire at a clock time, like “every day at 3:30 .” They’re configured with the OnCalendar= option, whose syntax echoes the idea of cron’s fields but in a more explicit form: day of week, year-month-day, hour:minute:second . An asterisk means “any value.”

OnCalendar=*-*-* 03:30:00    # every day at 3:30
OnCalendar=Mon..Fri 09:00    # Monday to Friday at 9:00

There are also handy shorthands like hourly, daily, weekly, monthly: for example, daily corresponds to *-*-* 00:00:00.

Monotonic timers, by contrast, don’t look at the clock but at the time elapsed since an event: OnBootSec= measures from when the machine booted, OnUnitActiveSec= from when the linked unit was last started. They’re useful for expressing things like “15 minutes after boot, then every hour.”

What cron is, and why we talk about an alternative

To see why people like timers, it helps to recall what cron does. cron is the long-standing Linux (and Unix) program for scheduling recurring tasks: a daemon that, in the words of its manual, will “run this command at this time on this date.” The schedule is written in a file, the crontab, with five fields for minute, hour, day of month, month, and day of week.

cron does one thing, and it has done it reliably for decades: run a command at a time. The catch is everything else, namely where the output goes, what happens if the machine was off at the scheduled time, and how to know when it will run next. Those concerns aren’t cron’s job. systemd timers exist precisely to cover that “everything else.”

The advantages of timers

Logs end up in the journal

systemd keeps a centralized record of events, the journal, managed by a service called journald. By default, the output of every service, both normal output and error messages, is collected there and organized by unit. With cron, traditionally, a task’s output was mailed to the user (via the MAILTO option) or risked being lost. With a timer, a single command reads back the entire history of a task:

journalctl -u backup.service     # full history of the job
systemctl list-timers            # all timers and their next run

Catching up on missed runs

With cron, if the machine was off at the scheduled time, that run is simply skipped and nobody records it. Timers offer the Persistent=true option: systemd stores on disk when the task last ran and, at the next startup, if it should have fired at least once in the meantime, it runs it right away. It’s designed to catch up on missed runs after downtime, and it applies to calendar timers.

Dependencies and ordering

A timer starts a unit, and a unit lives inside systemd’s dependency graph. So you can ask for a task to run “only after the network is ready” or “only after a disk is mounted.” cron, by contrast, fires at the time regardless of whether those conditions hold.

Verifiability

One last practical advantage: you can check everything without waiting for the clock. systemctl list-timers shows every timer with its next run, and the linked service can be started by hand to test it, independent of the schedule.

When cron is still fine

It’s not a contest. For a simple task, with no need for structured logs, dependencies, or catch-up, cron is still shorter to write and is available even on systems that don’t use systemd. But when it matters to know what happened, that is, the output, the outcome, and the next run, or when you need ordering and recovery after an interruption, timers offer a lot more in exchange for one extra file to write.

In short

systemd is the system and service manager that, on most modern Linux systems, starts and supervises the machine’s programs. It describes everything as a unit, and among those are timers: a way to schedule recurring tasks that, compared to cron, adds logging in the journal, catch-up for missed runs, and dependencies. cron isn’t obsolete, but for anyone who needs to really know what their scheduled jobs are doing, timers are the modern alternative.

# What systemd Is and What Timers Are (the Modern Alternative to cron)