HN Debrief

Love systemd timers

  • Infrastructure
  • Developer Tools
  • Open Source
  • Programming

The post is a practical pitch for replacing cron with systemd timers on Linux. It walks through what a timer and its paired service file look like, then argues that timers beat cron because they share the same execution model as the rest of the system, can be listed and inspected centrally, log through journald, can catch up after missed runs, and support features like randomized delays and direct manual triggering via the underlying service. For readers who have only ever used cron, the key distinction is that a timer is just one trigger for a normal systemd unit, so the scheduled job plugs into the same process supervision, logging, dependency handling, and failure reporting as any other service.

If you run Linux systems that already use systemd, timers are worth standardizing on for anything you may need to inspect, retry, stagger, or debug. Keep cron for the tiny cases if you want, but do not assume the migration case is about prettier syntax. It is mostly about observability, integration, and operational control.

Discussion mood

Mostly positive on systemd timers, with enthusiasm driven by better observability, missed-run handling, randomization, and integration with the rest of systemd. The negative tone came from two places: long-running distrust of systemd as a project, and skepticism that timer syntax or environment handling is actually simpler than cron's.

Key insights

  1. 01

    Persistent timers are catch-up, not a queue

    `Persistent=true` only gives you one compensating run after missed schedule points, not a replay of every missed execution. That makes it a good fit for backups and other idempotent maintenance work on laptops or hosts that are often off, but a bad fit if you actually need per-run delivery guarantees or backlog management.

    Use persistent timers for jobs where "run at least once after downtime" is enough. If missed executions need ordering, rate limiting, or visibility as discrete work items, move to a real queue or scheduler.

      Attribution:
    • PunchyHamster #1
    • gchamonlive #1 #2
  2. 02

    Randomized scheduling is a real operational win

    The useful upgrade over plain cron is not fancy calendar syntax. It is built-in jitter that spreads jobs across machines without wrapper scripts or config generation. Commenters highlighted stable offsets for backups and maintenance tasks, which avoids synchronized spikes on shared storage or networks while keeping each host's schedule predictable.

    For fleet-wide jobs, stop hand-staggering minute fields or sleeping inside scripts. Use timer randomization and pair it with explicit locking if overlapping runs would still hurt you.

      Attribution:
    • PunchyHamster #1 #2
    • stryan #1
    • c-hendricks #1
  3. 03

    The real advantage is sharing the service model

    Timers matter because they trigger normal units, not because they are a shinier cron clone. The same job can be started manually, observed in `journalctl`, monitored for failures, and governed by the same dependencies and resource controls as the rest of the system. That removes a lot of one-off scheduling weirdness and turns scheduled work into standard service management.

    If you already operate around `systemctl` and `journalctl`, model recurring jobs as services first and schedules second. That makes debugging and policy enforcement much more consistent.

      Attribution:
    • jchw #1 #2
    • dmuth #1
    • kayson #1
  4. 04

    Power management and coalescing change laptop use cases

    One commenter pointed to features that rarely show up in cron debates but matter on endpoints and portable machines: waking from sleep, coalescing nearby jobs to reduce power churn, and controlling timer accuracy so tasks run together instead of constantly nudging the machine awake. That is a different class of scheduling problem than the classic always-on server cron job.

    On laptops, developer workstations, and intermittently sleeping devices, choose timers based on power behavior as much as schedule syntax. Coalescing and wake support can be the deciding feature.

      Attribution:
    • sophacles #1
    • PunchyHamster #1
  5. 05

    Template units cut boilerplate for repeated jobs

    Systemd's `@` template units let one timer or service definition parameterize many similar jobs. Instead of creating separate unit files for every script or certificate renewal target, you can pass an instance name and reuse the same definition. That is a more scalable pattern than duplicating near-identical cron entries across hosts.

    When you have many scheduled jobs with the same lifecycle but different inputs, use templated units instead of copying service files. It keeps review and rollout manageable.

      Attribution:
    • tpmoney #1
  6. 06

    Systemd calendar syntax is broader, not simpler

    Several detailed replies cut through the syntax bikeshedding. The fair claim is that systemd's calendar grammar is closer to ISO 8601 and can express cases many cron implementations cannot, especially around seconds, years, last-day logic, and weekday plus date combinations. The unfair claim is that this makes it easier in general. For common jobs, cron is terser. For advanced jobs, both are weird and you will check the manual either way.

    Sell timer migration on capability and integration, not on a promise of prettier scheduling strings. Teams will accept the grammar if the operational payoff is clear.

      Attribution:
    • harshreality #1 #2 #3

Against the grain

  1. 01

    Timers can fail in opaque ways

    A detailed production story described a `logrotate` timer that stopped firing on one VM out of many identical systems, with no clear local explanation and an upstream issue suggesting a long-standing edge case. The point is not that cron never fails. It is that systemd's internal interactions can be hard to reason about when they do fail, and the recovery path may be little more than changing options until the problem disappears.

    Do not treat timers as self-validating just because they integrate with systemd. Add monitoring for expected execution and last-success timestamps, especially for jobs like log rotation and backups.

      Attribution:
    • simoncion #1 #2
    • htx80nerd #1
  2. 02

    Cron still wins on immediacy

    Several skeptics argued that for the common case of "run this command every so often," cron remains easier to remember, faster to type, and less file-heavy. They conceded that systemd can do more, but not that it lowered the mental load. If the job is small and disposable, the extra ceremony of paired unit files and systemd-specific directories is real friction.

    Keep a simple path for trivial scheduled tasks. If you force every tiny job into full service-plus-timer boilerplate, people will reach for ad hoc workarounds instead.

      Attribution:
    • eqvinox #1
    • simoncion #1 #2 #3
  3. 03

    Some cron gaps are implementation gaps

    A recurring objection was that the post sometimes blamed cron itself for features that exist in common cron variants or adjacent tools. Anacron covers missed daily-style jobs. `RANDOM_DELAY` exists in some cron implementations. `CRON_TZ` exists too. That weakens any argument that timers are categorically replacing a frozen 1970s baseline.

    Check which cron you actually have before declaring a feature missing. The migration case is stronger when it focuses on unified service management, not on straw-manning older tools.

      Attribution:
    • mid-kid #1
    • simoncion #1 #2
    • 6031769 #1
  4. 04

    Standardization can outweigh elegance, but not erase lock-in concerns

    Even some people who dislike systemd's design said they still use it because software now ships units, timers, logging hooks, and related integration by default. That is a pragmatic endorsement, not affection. The flip side is a concern that convenience comes from one expanding control plane absorbing more of Linux, which makes opting out harder over time.

    Adopting timers may be the practical choice on mainstream Linux, but treat that as platform alignment rather than proof that the architecture debate is settled. Keep portability in mind if your software must run outside systemd-heavy distros.

      Attribution:
    • porridgeraisin #1
    • rconti #1
    • the_real_cher #1

In plain english

anacron ↩
A scheduler often used with cron to run periodic jobs that were missed because the machine was off.
cron ↩
A long-standing Unix scheduler that runs commands at specified times based on a compact time expression.
CRON_TZ ↩
A cron setting that lets a crontab use a specific time zone for its schedule.
ISO 8601 ↩
An international standard for writing dates and times in a consistent format.
journalctl ↩
The command-line tool used to query and view logs stored by journald.
journald ↩
The logging component of systemd that collects and stores logs for services and the system.
logrotate ↩
A utility that rotates, compresses, and removes old log files on Unix-like systems.
PATH ↩
An environment variable that tells the shell which directories to search for executable commands.
Persistent=true ↩
A systemd timer option that runs the job once after boot if one or more scheduled runs were missed while the system was off.
RANDOM_DELAY ↩
A cron feature in some implementations that delays job start by a random amount of time.
RandomizedDelaySec ↩
A systemd timer option that adds a random delay to each activation time.
RandomizedOffsetSec ↩
A systemd timer option that adds a stable random offset to a timer so different machines do not all run the same job at once.
systemd ↩
A Linux system and service manager used to start, stop, supervise, and configure background services.

Reference links

Systemd documentation and tools

Cron references and variants

Alternative schedulers and queueing tools

  • Snooze
    Suggested as a non-systemd scheduler that can persist last-run state across downtime
  • waitlock
    Suggested for semaphore-style locking when coordinating many scheduled jobs without a full queue
  • dron
    Suggested as a tool for generating many unit files instead of managing them by hand

Deployment and integration examples

  • Borg automated backups repo
    Shared as a concrete example of using timers for resilient backups
  • Quadlet Nix modules
    Referenced in a NixOS subthread about Podman Quadlets and systemd integration
  • compose2nix
    Mentioned indirectly as a competing approach in the Quadlet discussion, though only the quadlet-nix link was explicitly posted

Related scheduling syntax discussions

Bugs and edge cases

  • systemd issue 6680
    Linked as the likely upstream bug behind a timer that stopped firing unexpectedly

Other related reading