Developer tools · Crontab generator
Cron vs systemd timers: what each does better for scheduled jobs
· Background
cron systemd portability
Modern Linux systems ship both, and they overlap without being interchangeable. This post compares syntax, logging, dependencies, overlap handling and portability so you can choose deliberately.
The repository implements one scheduler grammar, not a two-way comparison
A host may offer more than one scheduling system, but ToolAcre implements only a five-field cron parser. It has no systemd unit reader, writer or converter. A fair comparison needs evidence from both sides; this repository supplies detailed evidence for only one.
Use the route to build a cron candidate and expose its calendar semantics. Do not interpret the absence of timer features as a verdict that cron is better or worse. The product boundary is narrower: it helps readers understand one expression before they decide where that expression belongs.
OnCalendar syntax and systemd-analyze are outside the codebase
`OnCalendar=` is not accepted by `parseCron`, and `systemd-analyze` is never invoked. The workbook’s syntax comparison would require systemd documentation and executable tests that are not listed among article sources. Reproducing it from memory would violate the authoring contract.
The proven syntax here consists of five positions plus supported aliases. If a team considers a timer unit, construct and validate that calendar with its native tooling. Similar words such as daily or hourly do not make the grammars interchangeable.
Logging and status differences require systemd and cron sources
ToolAcre contains no mail, journal, status or service-manager integration. It cannot compare how failures are recorded or queried. Its own status element reports parse and preview errors in the browser, which is unrelated to the eventual job’s runtime status.
Evaluate observability with real target commands and logs. Preserve the cron preview as a timing expectation, not as evidence that either scheduler started an action. This keeps interface feedback separate from operating-system evidence.
Dependencies and environment are not represented by a five-field expression
A five-field expression carries no dependency graph or environment file. The generator cannot say that a network is ready, select an account or populate variables. Those concerns exist regardless of whether the calendar fragment itself is correct.
When selecting a scheduler, list the action’s prerequisites and identify where each can be expressed and verified. ToolAcre can support the cron-calendar row in that matrix. It cannot populate the other columns or certify a timer configuration it never parses.
Overlap and missed-run policies are external to ToolAcre
Overlap control, catch-up after downtime and active-service behavior are not present in `cron.js`. The next-run function computes potential wall-clock instants only. It does not persist a last-run marker, inspect a running process or retry a missed event.
Any comparison of policies must use the actual cron and timer implementations under consideration. Avoid turning a common operational pattern into a universal promise. A generator’s calendar math is necessary for review but insufficient for lifecycle semantics.
Portability claims require target evidence
The claim that cron exists on every Unix-like system is broader than repository evidence. Even when an implementation is common, versions and extensions differ. ToolAcre itself accepts aliases and names that a minimal target may not recognize.
Portability should be tested by consulting the destination and choosing grammar it documents. The route helps produce explicit lists as an alternative to steps, but cannot guarantee either form elsewhere. Report compatibility per target rather than as a slogan about platforms.
Container and cloud schedulers are also out of scope
Kubernetes and cloud schedulers may use cron-like strings with their own field counts, time-zone settings and policies. No clients or schemas for those products appear here. ToolAcre should not be used to validate them by resemblance.
Count fields and identify dialect before pasting. If the destination explicitly uses compatible five-field syntax, compare a harmless example. If it adds semantics, use its validator. The browser’s exact-five-fields error is a guardrail, not a universal scheduler detector.
Takeaway: cron for portability and simplicity, timers for integration — and the generator covers the cron side
The honest comparison result is asymmetric: ToolAcre can explain its cron side in detail and can only mark the timer side as unverified. That is still useful. It prevents a schedule decision from being made on invented differences or remembered command names.
Build the cron option, capture its description and preview, then research the alternative from authoritative sources. Choose based on verified requirements such as dependencies, observability and missed-run policy. The generator supplies one candidate, not the final architectural decision.