Your team runs its nightly jobs from crontab entries and is considering moving them to systemd timer units. What do timers actually give you that cron does not, and what do you give up?

## What cron actually is A cron daemon reads crontab files — the per-user ones edited with `crontab -e`, plus `/etc/crontab` and drop-ins under `/etc/cron.d` — and forks a shell to run a command line at matching minutes. That is the whole model, and its virtues are real: one line per job, portable to every Unix, understood by everyone. Its limits are all consequences of the same minimalism — the daemon has no idea whether your job succeeded, how long it ran, what it spawned, or whether the last copy has finished. ## Where the output goes Cron mails a job's stdout and stderr to the crontab's owner (or to `MAILTO=`). On a modern server with no local mail transfer agent installed, that output is simply lost, which is why so many cron jobs end with a hand-rolled `>> /var/log/thing.log 2>&1` and a separate logrotate config to stop it eating the disk. A systemd service's stdout and stderr are captured by the journal by default. You get the job's output, its start and stop timestamps and its exit status recorded against the unit, retained under the journal's own size limits, with no redirection and no extra rotation config. Failure becomes queryable rather than something you notice a week later. ## Ordering and dependencies Cron has `@reboot` and nothing else; a boot-time job that needs the network is traditionally handled with `sleep 30` and hope. A timer-triggered job is a unit, so it can declare ordering against other units — `After=network-online.target`, for example — and systemd resolves that instead of you timing it by hand. ## Resource control and process hygiene Every systemd service runs in its own cgroup. Two things follow. First, you can constrain it declaratively in the `[Service]` section: ```ini [Service] Type=oneshot ExecStart=/usr/local/bin/reindex.sh CPUQuota=40% MemoryMax=1G IOWeight=20 ``` A nightly reindex that used to page someone at 03:00 by saturating the box is now bounded. Second, everything the job forks stays in that cgroup and is accounted to it and cleaned up with it. Cron's children, by contrast, are just processes; a job that leaks a background helper leaves it running until someone notices. ## Overlap If a cron job scheduled every five minutes takes seven, you get overlapping copies, and the standard fix is your own lock (`flock`). systemd will not run a second instance of an already-active unit, so a slow run delays the next trigger rather than stacking on top of it. ## Visibility ```bash systemctl list-timers --all ``` One command lists every timer with its next elapse, time remaining, last elapse and the unit it activates. The cron equivalent is walking every user's crontab plus `/etc/crontab` plus `/etc/cron.d` plus the `cron.daily`/`cron.hourly` directories — which is exactly why forgotten cron jobs are a genre of incident. ## Running it by hand With cron, testing a job means copying the command line out of the crontab and running it in your shell, where PATH, environment, working directory and user are all different from the real thing — the classic "works when I run it, fails at 3am". With a timer, `systemctl start reindex.service` runs exactly the unit that the schedule runs, in the same environment. ## Catching a missed run If the machine is off at the scheduled minute, cron simply skips it; distributions bolt on anacron for the `cron.daily` class of jobs. A systemd timer with `Persistent=true` records the last trigger on disk and runs once shortly after the machine comes back. ## What you actually give up - **Boilerplate.** Two unit files and a `daemon-reload` per job, versus one crontab line. For a handful of trivial jobs that is a real cost. - **Portability.** Timers exist only where systemd does. A script that must also run on a BSD or a minimal container image needs cron or an in-process scheduler. - **Familiarity.** Five-field cron syntax is universal knowledge; `OnCalendar=` and monotonic timers are not, and a team that half-knows them will write schedules that do not mean what they think. - **A different environment, not a richer one.** Services do not inherit a login environment either; you still specify absolute paths, `WorkingDirectory=`, `User=` and `Environment=` explicitly. ## The honest answer in an interview For anything that matters operationally — jobs whose failure you need to see, jobs that need bounding, jobs that must be inventoried across a fleet — timers win, and the two files are worth it. For a personal one-liner on a box you own, cron is still fine, and saying so is a better answer than claiming timers are strictly superior.