I still like cron. I know there are more sophisticated schedulers, orchestrators, queues, and event systems. Many of them are excellent. Still, for a certain class of work, cron has the decency to be obvious.
Run this thing at this time. Run it every few minutes. Stay quiet if there is nothing to report. Complain if something breaks. That covers a surprising amount of operational ground when the job is small, bounded, and well-instrumented.
The danger with cron is not that it is simple. The danger is invisible failure. A scheduled task without logging, alerting, or a clear output contract becomes a ghost. It may be helping. It may be dead. It may be slowly filling a disk while everyone enjoys their weekend.
The good pattern is boring: deterministic script, safe permissions, explicit environment, useful logs, quiet success, loud failure, and a way to run the job manually. If the output is meant for a human, make the message concise. If there is no news, send nothing. Silence should mean normal, not “we forgot to check.”
Cron is a hammer, not a platform strategy. But sometimes the problem is a nail, and pretending otherwise is how teams accidentally build a cathedral around a reminder.
Cron's virtue is obviousness
Cron has the rare software virtue of being easy to explain to a tired person. Run this command at this time. Run it every hour. Run it every morning. That is not enough for every system, but it is enough for more systems than people want to admit.
The danger is not simplicity. The danger is invisible simplicity. A cron job with no logs, no clear output, and no failure alert is a ghost with a schedule. It may be working. It may have died last month. It may be writing errors into a place nobody checks.
So the pattern needs discipline: explicit environment, deterministic script, quiet success, loud failure, and a manual way to run the same job. If those are present, cron can be a perfectly respectable part of an operating system.
When I reach for it
I reach for cron when the job is bounded and boring: check a feed, refresh a cache, run a monitor, build a digest, clean a temporary directory, send a heartbeat, or look for a threshold crossing. If the job needs orchestration, retries, distributed state, and complex dependencies, use something else. Cron is not offended.
What I like is that cron does not try to become a lifestyle. It does the scheduled thing and gets out of the way. In a world where every tool wants to be a platform, there is something refreshing about a tool that still knows how to be a tool.
The real rule is simple: if normal means nothing happened, the job should be silent. If something broke, it should say exactly what broke. That one rule would improve half the automation in the world by lunchtime.
The practical version
The practical version of why i still like cron is not a slogan. It is a set of decisions I have to make when the week is already crowded. For why i still like cron, the questions are concrete: what gets automated, what gets reviewed, what gets ignored, and what gets a hard stop? The answer changes by context, but the habit is the same: name the risk before building the tool around it.
For this topic, the important words for me are still, like, cron. That may sound like a strange way to frame a technical post, but it keeps why i still like cron attached to actual work instead of floating away into consultant fog. If why i still like cron does not change a queue, a dashboard, a draft, a check, a handoff, or a decision, then I probably do not need a whole system around it. I need a note, a script, or maybe just the humility to delete the idea.
This is also where my tolerance for vague productivity language around why i still like cron has dropped. I do not want a system that merely produces more artifacts under a sharper title. More artifacts can make the work feel heavier. I want why i still like cron to collapse uncertainty: here is the state, here is the source, here is the next action, here is what still needs a human, and here is the proof that the claim is not decorative.
That is the through-line in this particular post: still, like, cron only matter if they make responsibility easier to carry. The best systems do not remove judgment. They protect it from trivia, preserve it for the moment that matters, and leave a trail clear enough that future me can understand why the decision was made.
The other test is whether why i still like cron survives a normal week. Not a conference week. Not a clean-room demo. A normal week with context switching, half-finished drafts, children in the schedule, client work, infrastructure surprises, and a brain that does not need one more place to remember things manually. If this idea only works when I am rested and staring directly at it, it is not a system yet. It is a hopeful arrangement.
That standard sounds harsh, but it keeps this subject honest. The useful version of why i still like cron has to meet me where the work actually happens: in queues, folders, tickets, dashboards, drafts, logs, and review gates. If it cannot survive there, it does not matter how good it looked in the first pass.