It was recently pointed out to me that an alternative to cron exists, namely systemd timers.

However, I know nothing about systemd or systemd timers. I have only used cron.

There is a little discussion in the Arch Wiki. However, I'm looking for a detailed comparison between cron and systemd timers, focusing on pros and cons. I use Debian, but I would like a general comparison for all systems for which these two alternatives are available. This set may include only Linux distributions.

Here is what I know.

Cron is very old, going back to the late 1970s. The original author of cron is Ken Thompson, the creator of Unix. Vixie cron, of which the crons in modern Linux distributions are direct descendants, dates from 1987.

Systemd is much newer, and somewhat controversial. Wikipedia tells me its initial release was 30 March 2010.

So, my current list of advantages of cron over systemd timers is:

  1. Cron is guaranteed to be in any Unix-like system, in the sense of being an installable supported piece of software. That is not going to change. In contrast, systemd may or may not remain in Linux distributions in the future. It is mainly an init system, and may be replaced by a different init system.

  2. Cron is simple to use. Definitely simpler than systemd timers.

The corresponding list of advantages of systemd timers over cron is:

  1. Systemd timers may be more flexible and capable. But I'd like examples of that.

So, to summarise, here are some things it would be good to see in an answer:

  1. A detailed comparison of cron vs systemd timers, including pros and cons of using each.
  2. Examples of things one can do that the other cannot.
  3. At least one side-by-side comparison of a cron script vs a systemd timers script.
  • 4
    "Cron is guaranteed to be in any Unix-like system. That is not going to change." – I would strongly debate this. While historically cron has often been included in the base setup of Unix installations, on most systems today it's simply an arbitrary optional software package among others. In fact, there are several popular cron alternatives around (e.g. anacron, fcron, jobber) which may be preferable to cron. cron's functionality is not essential for a system's operation the way systemd or init is, so if you're concerned about current and future portability, I'd rather not place my bets on it. – Guido Apr 23 '16 at 13:52
  • 6
    That's quite a list of things you want in an answer. I think maybe you should spend some time learning the tools yourself and see if you can formulate those answers on your own, and if you have specific things you don't understand, ask them here. – larsks Apr 23 '16 at 14:56
  • 5
    Not really. I've said all i want to say on the topic. Getting into an extended discussion about anything involving systemd is worse than pointless - some think that the minor benefits that systemd brings are worth the corporate monopolisation of the linux ecosystem. Others don't. – cas Apr 24 '16 at 10:35
  • 7
    "Cron is very old, going back to the late 1970s." Factually correct, but completely irrelevant so long as the packages on your system are being maintained in a sensible and stable way. The sun is also very old, but I hope that doesn't mean we should replace it with something shinier and newer. – Otheus Apr 28 '16 at 8:22
  • 5
    @Otheus I think you're taking that part wrong—saying something has been around for a long time isn't an insult. At least to a lot of Unix folks. It's more like saying a house is hundreds of years old—that certainly means it'll have some problems, some stuff will be weird from retrofitting, but it also has a certain charm, and it must have been built well. It's not to say its decrepit. It's a simple tool that has proved useful for four decades. – derobert Apr 29 '16 at 19:22

Here are some points about those two:

  1. checking what your cron job really does can be kind of a mess, but all systemd timer events are carefully logged in systemd journal like the other systemd units based on the event that makes things much easier.

  2. systemd timers are systemd services with all their capabilities for resource management, IO CPU scheduling, ...
    There is a list :

    • systemcall filters
    • user/group ids
    • membershipcontrols
    • nice value
    • OOM score
    • IO scheduling class and priority
    • CPU scheduling policy CPU
    • affinity umask
    • timer slacks
    • secure bits
    • network access and ,...
  3. with the dependencies option just like other systemd services there can be dependencies on activation time.

  4. Units can be activated in different ways, also combination of them can be configured. services can be started and triggered by different events like user, boot, hardware state changes or for example 5mins after some hardware plugged and ,...

  5. much easier configuration some files and straight forward tags to do variety of customizations based on your needs with systemd timers.

  6. Easily enable/disable the whole thing with:

    systemctl enable/disable 

    and kill all the job's children with:

    systemctl start/stop
  7. systemd timers can be scheduled with calenders and monotonic times, which can be really useful in case of different timezones and ,...

  8. systemd time events (calendar) are more accurate than cron (seems 1s precision)

  9. systemd time events are more meaningful, for those recurring ones or even those that should occur once, here is an example from the document:

    Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-*00:00:00
      Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
                    Wed *-1 → Wed *-*-01 00:00:00
            Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00
                 Wed, 17:48 → Wed *-*-* 17:48:00 
  10. From the CPU usage view point systemd timer wakes the CPU on the elapsed time but cron does that more often.

  11. Timer events can be scheduled based on finish times of executions some delays can be set between executions.

  12. The communication with other programs is also notable sometimes it's needed for some other programs to know timers and the state of their tasks.

  • 2
    That's a good effort, thank you. However, more direct comparisons with cron would be helpful, including an example. Also, some of what you write is not completely clear, e.g. "from the CPU usage view point systemd timer wakes the CPU on the elapsed time but cron does that more often." – Faheem Mitha May 5 '16 at 8:49
  • Hello, @F.sb ! Your answer seems to imply that you can schedule jobs using different time zones. Is this correct? How would you do that? It would be a significant advantage over standard implementations of cron, but I couldn't find any info about it, except for man systemd.time which seems to contradict it: Non-local timezones except for UTC are not supported. – Tad Lispy May 24 '17 at 15:48
  • The dependencies are handy. For example if the host backup runs as a systemd timer then you can use dependencies to ensure that a database export completes immediately prior to the backup. – vk5tu Nov 22 '17 at 11:17
  • 6
    Please be more honest up front. You start off by saying these are some point about the two, and then continue by listing the advantages of your preferred choice. It isn't bad that you have a preference, but then you should state so up front. On top of that, the fact that it's all in favor of one system and doesn't look at the pros that system has makes me feel this answer is skewed. – Jasper Dec 4 '17 at 16:06
  • 2
    @jasper dear i use both of them based on my needs, and it's always your choice to choose one based on your needs, i just mentioned some facts based on docs and manuals. – F.sb Dec 6 '17 at 9:30

Straight from the horse's mouth, so to speak: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

An excerpt from the page above:


The main benefits of using timers come from each job having its own systemd service. Some of these benefits are:

  • Jobs can be easily started independently of their timers. This simplifies debugging.
  • Each job can be configured to run in a specific environment (see systemd.exec(5)).
  • Jobs can be attached to cgroups.
  • Jobs can be set up to depend on other systemd units.
  • Jobs are logged in the systemd journal for easy debugging.


Some things that are easy to do with cron are difficult to do with timer units alone.

  • Complexity: to set up a timed job with systemd you create two files and run a couple systemctl commands. Compare that to adding a single line to a crontab.
  • Emails: there is no built-in equivalent to cron's MAILTO for sending emails on job failure. See the next section for an example of setting up an equivalent using OnFailure=.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.