https://devops.sarmento.org/en/tags/cron-alternative/Recent content in Cron-Alternative on /var/log/janioHugoenFri, 17 Apr 2026 11:20:00 +0000https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/Mon, 23 Mar 2026 21:29:00 +0000https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/<p>In the <a href="https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/">previous post</a> I showed how systemd timers replace cron on Debian and Ubuntu servers with concrete advantages: integrated logging, missed execution recovery, declarative dependencies, and resource control. The logic is compelling and the migration is straightforward — as long as you are on a system running systemd. But if your daily routine includes a Mac, it is a different story.</p> <p>macOS has its own scheduling system, predating systemd and built on a different philosophy. It is called <a href="https://devops.sarmento.org/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/">launchd</a>, it has been around since Mac OS X Tiger in 2005, and it is responsible for practically everything that runs in the background on the system — from internal Apple services to that Spotify updater you never asked to install. Despite being the official and recommended way to schedule tasks on a Mac, launchd lives in a kind of blind spot: people coming from Linux tend to reach for cron out of reflex, and Mac users without a sysadmin background do not even know the option exists.</p>https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/Mon, 23 Mar 2026 06:21:00 +0000https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/<p>If you have been managing Debian or Ubuntu servers for any length of time, you probably have a comfort relationship with cron. One line in the crontab, five scheduling fields, and the path to a script — done. cron has worked this way since the 1970s, and that simplicity is exactly what kept it relevant for so long.</p> <p>The problem is that &ldquo;it works&rdquo; and &ldquo;it works well in 2026&rdquo; are different things. When a job fails silently at three in the morning, when you need to figure out which of twenty crontabs scattered across the system contains that one specific task, or when the server reboots and simply misses the execution that should have happened during downtime — those are the moments when cron shows it was designed for an era with different expectations around observability and resilience.</p>