<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Timer-Management on /var/log/janio</title><link>https://devops.sarmento.org/en/tags/timer-management/</link><description>Recent content in Timer-Management on /var/log/janio</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 11 Apr 2026 11:22:00 +0000</lastBuildDate><atom:link href="https://devops.sarmento.org/en/tags/timer-management/index.xml" rel="self" type="application/rss+xml"/><item><title>Systemd Timers: Time to Retire cron</title><link>https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/</link><pubDate>Mon, 23 Mar 2026 06:21:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/</guid><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The problem is that &amp;ldquo;it works&amp;rdquo; and &amp;ldquo;it works well in 2026&amp;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.&lt;/p&gt;</description></item></channel></rss>