The ticket usually arrives from the wrong direction. Nobody reports “the scheduler is broken.” Somebody asks for a restore, and the newest dump in the backup directory is three weeks old.<\/p>\n\n\n\n
The crontab entry is still there. The script still works when you run it by hand. Nothing in the monitoring went red, because nothing was watching whether the job ran at all. It was watching whether the server was up.<\/p>\n\n\n\n
That is the real question behind cron vs systemd timers, and it has almost nothing to do with syntax. Both tools can run a command at 2 a.m. The difference is what happens on the night the command doesn’t run, and how long it takes anyone to find out.<\/p>\n\n\n\n
This post compares the two by failure family rather than by feature list: missed runs, overlapping runs, environment surprises, output that goes nowhere, and jobs that eat the machine. Then a decision procedure, the same job written both ways, and how to debug each one when it goes quiet.<\/p>\n\n\n\n
Scheduled jobs fail silently far more often than they fail loudly. A job that crashes with a stack trace gets fixed the same week. A job that stopped firing six weeks ago gets found during an incident.<\/p>\n\n\n\n
Cron’s default answer to “what happened?” is to mail the job’s output to the owning user. On a server with no local mail transfer agent configured, which is most servers built in the last decade, that output is generated and then discarded. The daemon logs that it started<\/em> the command. It does not log what the command printed, and in most implementations it does not log the exit status either.<\/p>\n\n\n\n So you get a log line saying cron ran your backup, every night, forever, including on the nights the backup wrote nothing. That line is the trap. It looks like evidence.<\/p>\n\n\n\n systemd timers hand this to journald instead. Standard output and standard error from the triggered service land in the journal, tagged with the unit name, alongside the exit status and the runtime. That is the single biggest practical difference between the two, and it is the reason most of my new scheduled work goes into timers.<\/p>\n\n\n\n Neither one alerts you. Both will happily not run for a month while you sleep well. Observability is not monitoring, and I’ll come back to that.<\/p>\n\n\n\n Cron is one line in one file. There is no unit to reload, no second file to keep in sync, no install section to get wrong. It also runs where systemd does not. BSD hosts, Alpine images, containers, appliance firmware, embedded boxes, older enterprise systems still on a legacy init. If your configuration management has to cover a fleet that is not uniformly systemd, cron is the common denominator and it is not close.<\/p>\n\n\n\n Per-user scheduling is genuinely simpler too. A user runs A timer separates when<\/em> from what<\/em>. The Everything systemd knows how to do to a service, it will do to a scheduled job. Ordering after other units. Restart-on-failure. Runtime caps. Memory and CPU limits through cgroups. A dedicated user. A private You also get a schedule you can interrogate before it bites you. Cron has no memory. If the box was down, rebooting, or suspended when the schedule came round, that run is gone. Nothing catches it up and nothing records that it was skipped.<\/p>\n\n\n\n The traditional fix is anacron, which tracks the last successful run per job in a timestamp file and runs the job shortly after boot if the interval has lapsed. It is why the scripts in systemd folds that behaviour into a single directive:<\/p>\n\n\n\n With One caveat worth knowing: “immediately” means immediately. If you have twelve persistent timers and the box has been off for a week, all twelve fire within seconds of boot, on a machine that is still starting services. Pair This is the one that corrupts data. A sync job normally takes four minutes and runs every five. One night the remote end is slow, the run takes eleven minutes, and cron starts two more copies while the first is still writing.<\/p>\n\n\n\n Cron will not stop this. You have to do it yourself, and the standard tool is systemd gets this for free from its own model. A unit is either active or it isn’t. If One default is worth knowing. A calendar timer schedules its next elapse from the previous trigger time, so if a run overran, that next elapse is already in the past and the service fires again the moment it finishes. Newer systemd releases add a “It works when I run it manually” is the single most common scheduled-job bug, and both schedulers cause it, for the same reason: neither one gives your job an interactive login shell.<\/p>\n\n\n\n Cron runs the command with a short, hardcoded environment. Your shell profile is not sourced. Your Cron adds one hazard that is entirely its own. Inside a crontab, the percent sign is a metacharacter: it becomes a newline, and everything after the first one is fed to the command as standard input. So this looks fine and is broken:<\/p>\n\n\n\n There is no warning. The line parses, cron runs the truncated fragment, and the log says the job started. Anything with a systemd services get a minimal environment too, so the class of bug is identical. What differs is that the fix is declarative and lives with the unit rather than being hidden inside a wrapper script:<\/p>\n\n\n\n The honest summary: absolute paths for every binary solve most of this on either scheduler. The rest is solved by never putting logic in the schedule. Put it in a script and schedule the script.<\/p>\n\n\n\n Write systemd has two directives here and they pull in opposite directions, which is the part people get wrong:<\/p>\n\n\n\n If you want a timer to fire close to the stated second, lower Cron has no answer here beyond The two directives that earn their keep on a shared box are A nightly database dump that must not overlap, must not run before the database is up, and must catch up if the host was rebooted. In cron:<\/p>\n\n\n\n That handles overlap and captures output. It does not handle “the database wasn’t ready” or “the host was down”, and the log file is now your problem to rotate.<\/p>\n\n\n\n The systemd version is two files. First the service, which is the job:<\/p>\n\n\n\n Then the timer, which is only the schedule:<\/p>\n\n\n\n Because the two units share a base name, you do not need a Then the part people skip, which is verifying it before walking away:<\/p>\n\n\n\n Note that you enable the timer<\/em>, not the service. Enabling the service instead would try to run the job at every boot, which is a memorable way to learn the difference.<\/p>\n\n\n\n Work down this list and stop at the first line that applies. It resolves most cases in under a minute.<\/p>\n\n\n\n The migration question answers itself from that. Do not convert forty working crontab lines in a weekend. Write new scheduled work as timers, convert the jobs that have actually burned you, and leave the rest. Mixing both on one host is normal and supported. Just never schedule the same job in both places, which is easier to do than it sounds when a configuration management run and a manual edit disagree.<\/p>\n\n\n\n Establish what actually happened before you theorise. The daemon logs every job it starts, so the log tells you which of three situations you are in: cron never tried, cron tried and the command failed, or cron never saw the entry at all.<\/p>\n\n\n\n Then work through the usual suspects, roughly in order of how often they turn out to be the cause:<\/p>\n\n\n\n “Cron is deprecated.”<\/strong> It isn’t. It is packaged and supported on every mainstream distribution, and control panels, hosting providers and countless application installers write crontab entries as a matter of course. Nobody is removing it.<\/p>\n\n\n\n “Timers are too complicated for small jobs.”<\/strong> Two files is more typing, not more complexity. The complexity that matters is the wrapper script you write to get locking, logging and a runtime cap out of cron, and how well the next person understands it. Compare like for like.<\/p>\n\n\n\n “The journal means I have logging sorted.”<\/strong> The journal is a ring buffer with a size cap. If nobody set “Switching to timers will stop jobs failing silently.”<\/strong> This is the one I’d push back on hardest. Timers make failures visible<\/em>. They do not make them noticed<\/em>. Neither scheduler will ever tell you that a job did not run, because absence is not an event. That needs a dead man’s switch: the job pings a heartbeat endpoint on success, and something external alerts when the ping stops. Healthchecks.io, Cronitor and Better Stack all sell exactly this, and Healthchecks is open source if you would rather self-host it next to your own Grafana. If you already run Prometheus, writing a completion timestamp through the node exporter’s textfile collector and alerting on its age gets you the same property without another vendor.<\/p>\n\n\n\n “Just move everything to timers.”<\/strong> A mass migration of working jobs is a lot of change for no new capability, and every converted job is a chance to fat-finger a path. Convert on cause, not on principle.<\/p>\n\n\n\n For production jobs on a systemd host, generally yes: logging, dependency ordering, overlap protection, catch-up and resource limits are all built in rather than bolted on. For a one-line job on a box you own, cron’s simplicity is a real advantage and the timer buys you nothing you will use.<\/p>\n\n\n\n No. Cron implementations are still packaged and maintained across the major distributions. Some distributions do not install a cron daemon in minimal images by default, which is a packaging decision rather than a deprecation, so check with your package manager before assuming a fresh host has one.<\/p>\n\n\n\n Yes, and most real servers run both. The cron daemon itself is usually managed as a systemd service. The only rule is that a given job should be scheduled in exactly one place. Double-scheduling is what produces the “why did this run twice” ticket.<\/p>\n\n\n\n Wrap it in Not usefully. A container normally runs a single process without systemd as PID 1, so there is no service manager to own a timer. Schedule from outside the container instead: a host timer that runs the container, or the scheduler your platform provides. Podman is the exception worth knowing, since it can generate systemd units for containers and the host’s systemd drives them.<\/p>\n\n\n\n Move the command into a Cron vs systemd timers is not a contest between an old tool and a new one. Cron is a scheduler. A systemd timer is a scheduler attached to a supervisor, and the supervisor is what you are actually buying: dependency ordering, overlap protection, catch-up, resource limits, and output that lands somewhere you can read it.<\/p>\n\n\n\n Pick timers when a missed or duplicated run costs you something. Pick cron when it doesn’t. And whichever you pick, add a heartbeat, because the failure that hurts is not the job that crashes. It’s the job that stopped running while everything stayed green.<\/p>\n\n\n\n Scheduling is one of those areas where the problem is rarely the syntax. It’s the job nobody has checked since the person who wrote it left. This is the kind of work I take on:<\/p>\n\n\n\n If something on your server isn’t running when it should, send me the crontab line or the unit file and the journal output around the time it should have fired. That’s usually enough to tell you what’s wrong before we talk about anything else.<\/p>\n\n\n\nWhere cron still wins<\/h2>\n\n\n\n
crontab -e<\/code>, five fields, a command, done. For a job that trims a log directory on a box you own, that economy is not nothing.<\/p>\n\n\n\ncrontab -e<\/code> and owns their own jobs, with no root involvement and no unit files in \/etc<\/code>. On shared hosting and on control panels like DirectAdmin or cPanel, this is the only model available, and the panel writes the crontab for you.<\/p>\n\n\n\nWhere cron loses<\/h3>\n\n\n\n
\n\n
Where systemd timers win<\/h2>\n\n\n\n
.timer<\/code> unit holds the schedule. The .service<\/code> unit holds the job. That split feels like bureaucracy until the first time you need to run the job right now, out of band, without touching the schedule. Then it is just systemctl start myjob.service<\/code>, and the run is logged exactly like a scheduled one.<\/p>\n\n\n\n\/tmp<\/code>. A failure handler unit that fires when the job exits non-zero.<\/p>\n\n\n\nsystemctl list-timers<\/code> prints every timer on the box with its next and last elapse. systemd-analyze calendar<\/code> takes an expression and tells you exactly when it would fire, which is the closest thing either scheduler has to a unit test.<\/p>\n\n\n\nWhere systemd timers lose<\/h3>\n\n\n\n
\n\n
daemon-reload<\/code> and an enable<\/code> for every job. That is real friction when you have forty small jobs.<\/li>\n\n\nsystemd-analyze calendar<\/code> more often than you expect.<\/li>\n\n\n\/var\/log<\/code>, timer output is invisible to it until you point the shipper at journald.<\/li>\n\n<\/ul>\n\n\n\n
\n\n\n\nCron vs systemd timers, by failure family<\/h2>\n\n\n\n
The machine was off at 2 a.m.<\/h3>\n\n\n\n
\/etc\/cron.daily<\/code> still run on a laptop that is closed every night. The catch is that anacron works in whole days and only covers the cron.daily<\/code>, cron.weekly<\/code> and cron.monthly<\/code> directories by default. It does not help your custom job at 02:00.<\/p>\n\n\n\n[Timer]\nOnCalendar=*-*-* 02:00:00\nPersistent=true<\/code><\/pre>\n\n\n\nPersistent=true<\/code>, systemd writes a timestamp under \/var\/lib\/systemd\/timers\/<\/code> each time the timer fires. On boot it compares that stamp against the schedule, and if a run was missed it triggers immediately. This matters more than it sounds on any VPS you reboot for kernel updates, and a great deal on hosts at providers like Contabo or InterServer where you take maintenance windows on their timetable rather than yours.<\/p>\n\n\n\nPersistent=true<\/code> with RandomizedDelaySec=<\/code> so the catch-up is spread out.<\/p>\n\n\n\nTwo copies of the same job<\/h3>\n\n\n\n
flock<\/code> from util-linux:<\/p>\n\n\n\n*\/5 * * * * \/usr\/bin\/flock -n \/var\/lock\/sync.lock \/usr\/local\/bin\/sync.sh<\/code><\/pre>\n\n\n\n-n<\/code> means fail immediately rather than queue behind the running copy. Without it you build a backlog of processes all waiting for the same lock, which turns an overlap problem into a fork bomb with a slow fuse.<\/p>\n\n\n\nsync.service<\/code> is still running when the timer elapses, there is no second copy to start, because starting an already-active unit is a no-op. You do not have to remember anything.<\/p>\n\n\n\nDeferReactivation=<\/code> boolean that schedules from when the service went inactive instead, so an overrunning job waits for the next real slot. Check your distribution’s systemd version before relying on it.<\/p>\n\n\n\nThe environment your job actually gets<\/h3>\n\n\n\n
PATH<\/code> is much shorter than the one you tested with, which is why a script that calls docker<\/code>, wp<\/code>, aws<\/code> or a version-manager shim works from your terminal and fails from cron. The working directory is the user’s home, not wherever you happened to be standing.<\/p>\n\n\n\n# Truncated at the first %. The redirect never happens.\n0 2 * * * \/usr\/bin\/mysqldump app > \/backups\/app-$(date +%F).sql\n\n# Escaped. This is what you meant.\n0 2 * * * \/usr\/bin\/mysqldump app > \/backups\/app-$(date +%F).sql<\/code><\/pre>\n\n\n\ndate +<\/code> format string in a crontab deserves a second look.<\/p>\n\n\n\n[Service]\nType=oneshot\nUser=deploy\nWorkingDirectory=\/srv\/app\nEnvironment=PATH=\/usr\/local\/bin:\/usr\/bin:\/bin\nEnvironmentFile=\/etc\/myapp\/backup.env\nExecStart=\/usr\/local\/bin\/backup.sh<\/code><\/pre>\n\n\n\nEverything firing at once<\/h3>\n\n\n\n
0 0 * * *<\/code> on fifty hosts and fifty hosts hit your backup target, your package mirror or your API at exactly midnight. The classic cron answer is to hash the hostname into a minute offset in configuration management, which works and which every team reinvents.<\/p>\n\n\n\n\n\n
RandomizedDelaySec=<\/code> spreads timers apart<\/em>. It adds a delay between zero and the value you set, so identical schedules on many hosts land at different moments.<\/li>\n\n\nAccuracySec=<\/code> pulls timers together<\/em>. It lets systemd shift the firing time within a window to coalesce wakeups and save power. It defaults to one minute, which is why a timer set to 02:00:00 often fires a few seconds late.<\/li>\n\n<\/ul>\n\n\n\nAccuracySec=<\/code>. If you want to stagger a fleet, raise RandomizedDelaySec=<\/code>. Setting only AccuracySec=<\/code> to a large value and expecting it to spread load is the mistake, because coalescing is the opposite of spreading.<\/p>\n\n\n\nA job that eats the box<\/h3>\n\n\n\n
nice<\/code> and ionice<\/code> in front of the command, and a script that hangs forever will hang forever. A systemd service is a cgroup, so the limits are declarative and enforced:<\/p>\n\n\n\n[Service]\nType=oneshot\nMemoryMax=512M\nCPUQuota=40%\nIOWeight=20\nTimeoutStartSec=30min\nOnFailure=notify-failure@%n.service\nExecStart=\/usr\/local\/bin\/reindex.sh<\/code><\/pre>\n\n\n\nTimeoutStartSec=<\/code>, which kills a oneshot<\/code> job that has hung, and OnFailure=<\/code>, which starts another unit when this one exits non-zero. That second one is how you get a scheduled job to page you without wiring an alerting call into every script.<\/p>\n\n\n\n
\n\n\n\nThe same job written both ways<\/h2>\n\n\n\n
0 2 * * * \/usr\/bin\/flock -n \/var\/lock\/db-backup.lock \/usr\/local\/bin\/db-backup.sh >> \/var\/log\/db-backup.log 2>&1<\/code><\/pre>\n\n\n\n# \/etc\/systemd\/system\/db-backup.service\n[Unit]\nDescription=Nightly application database dump\nAfter=network-online.target mariadb.service\nWants=network-online.target\n\n[Service]\nType=oneshot\nUser=backup\nExecStart=\/usr\/local\/bin\/db-backup.sh\nTimeoutStartSec=45min<\/code><\/pre>\n\n\n\n# \/etc\/systemd\/system\/db-backup.timer\n[Unit]\nDescription=Run the nightly database dump\n\n[Timer]\nOnCalendar=*-*-* 02:00:00\nPersistent=true\nRandomizedDelaySec=15min\n\n[Install]\nWantedBy=timers.target<\/code><\/pre>\n\n\n\nUnit=<\/code> line. systemd pairs db-backup.timer<\/code> with db-backup.service<\/code> by convention. Add Unit=<\/code> only when the names differ.<\/p>\n\n\n\n# Check the units parse before you enable anything\nsystemd-analyze verify \/etc\/systemd\/system\/db-backup.*\n\n# Confirm the calendar expression means what you think\nsystemd-analyze calendar --iterations=5 \"*-*-* 02:00:00\"\n\nsystemctl daemon-reload\nsystemctl enable --now db-backup.timer\n\n# Next and last elapse for this timer\nsystemctl list-timers db-backup.timer\n\n# Run it now, out of band, without touching the schedule\nsystemctl start db-backup.service\njournalctl -u db-backup.service -n 50 --no-pager<\/code><\/pre>\n\n\n\nHow I’d decide<\/h2>\n\n\n\n
\n\n
Diagnosing a job that never fired<\/h2>\n\n\n\n
Cron<\/h3>\n\n\n\n
# Is the daemon running at all?\nsystemctl status crond # RHEL, AlmaLinux, Rocky\nsystemctl status cron # Debian, Ubuntu\n\n# What did it start, and when?\njournalctl -u crond --since \"24 hours ago\"\ngrep CRON \/var\/log\/syslog | tail -20 # Debian family\ntail -50 \/var\/log\/cron # RHEL family\n\n# Whose crontab are you actually looking at?\ncrontab -l -u deploy\nls -l \/etc\/cron.d\/<\/code><\/pre>\n\n\n\n\n\n
\/etc\/cron.d<\/code> where there is an extra user field before the command.<\/li>\n\n\n* * * * * env > \/tmp\/cron-env.txt 2>&1<\/code>, then compare it against your shell.<\/li>\n\n\n0 0 15 * 1<\/code> fires on the 15th and on every Monday.<\/li>\n\n\n>> \/var\/log\/myjob.log 2>&1<\/code> and wait for the next run.<\/li>\n\n<\/ul>\n\n\n\nsystemd<\/h3>\n\n\n\n
# Is the timer loaded and scheduled? --all shows inactive ones too\nsystemctl list-timers --all\n\n# Timer state, last trigger, next elapse\nsystemctl status db-backup.timer\n\n# What the job printed, and how it exited\njournalctl -u db-backup.service --since \"7 days ago\"\n\n# Prove the schedule independently of the unit\nsystemd-analyze calendar --iterations=3 \"Mon..Fri *-*-* 06:30:00\"<\/code><\/pre>\n\n\n\n\n\n
daemon-reload<\/code> and enable --now<\/code>.<\/li>\n\n\nsystemctl is-enabled<\/code> on both.<\/li>\n\n\nsystemctl --user<\/code>, the manager stops when the session ends unless you run loginctl enable-linger<\/code> for that user.<\/li>\n\n\nsystemd-analyze calendar<\/code> is how you find out.<\/li>\n\n\nUser=<\/code>, an ExecStart<\/code> path that does not exist, a WorkingDirectory<\/code> that is not there. The journal names the reason.<\/li>\n\n<\/ul>\n\n\n\nArguments that don’t survive contact<\/h2>\n\n\n\n
SystemMaxUse=<\/code> deliberately and nobody ships journal entries anywhere else, your evidence has a retention window you never chose. Check it before you rely on it.<\/p>\n\n\n\nFrequently asked questions<\/h2>\n\n\n\n
Are systemd timers better than cron?<\/h3>\n\n\n\n
Is cron deprecated or being removed?<\/h3>\n\n\n\n
Can cron and systemd timers coexist on the same server?<\/h3>\n\n\n\n
How do I see when a systemd timer will next run?<\/h3>\n\n\n\n
systemctl list-timers<\/code> shows next and last elapse for all active timers; add --all<\/code> to include inactive ones. To test an expression without creating a unit, use systemd-analyze calendar \"Mon..Fri *-*-* 06:30:00\"<\/code> with --iterations=N<\/code> for more fire times.<\/p>\n\n\n\nHow do I stop a cron job from overlapping itself?<\/h3>\n\n\n\n
flock -n<\/code> with a dedicated lock file. The -n<\/code> flag makes the new run exit straight away instead of queuing. Do not use a PID file you wrote yourself; it will leak a stale lock the first time the job is killed, and then the job stops running forever.<\/p>\n\n\n\nDo systemd timers work inside Docker containers?<\/h3>\n\n\n\n
How do I convert a crontab line to a systemd timer?<\/h3>\n\n\n\n
Type=oneshot<\/code> service with an absolute ExecStart<\/code>, then translate the five cron fields into an OnCalendar=<\/code> expression of the form DayOfWeek Year-Month-Day Hour:Minute:Second<\/code>. Verify the expression with systemd-analyze calendar<\/code>, enable the timer, then remove the crontab line only after you have seen a successful run in the journal.<\/p>\n\n\n\nThe one thing worth remembering<\/h2>\n\n\n\n
\n\n\n\nNeed a second pair of eyes on your scheduled jobs?<\/h2>\n\n\n\n
\n\n