A Hymn for the Unwritten Cron Job
There is a certain class of task that never quite earns a line in the crontab. It’s the script you run from your terminal on the first Tuesday of the month, after you’ve had your second coffee. It’s the log file you manually archive when you notice the disk usage tick over eighty percent. It’s the fleeting thought—a ghost of a procedure—that you execute so routinely you’ve stopped seeing it as a task at all. It lives in the muscle memory of your fingers, a sequence of commands tied to a mental trigger. This is the unwritten cron job, and it is a single point of failure in the system of you.
We’ve all got them. For me, it was the weekly verification of a particular backup stream from a legacy application. The backup itself was automated, a triumph of modern tooling. But the verification was a manual dance: ssh to the backup server, cd to a specific dated directory, run a custom checksum script, and eyeball the output for anomalies. It took three minutes, and I did it every Friday afternoon like clockwork. It was my quiet ritual, a small act of stewardship. The problem was, it was my ritual. It existed nowhere else.
The technique for capturing these ghosts is not complex, but it requires a moment of deliberate introspection. It’s a practice I’ve come to call ‘Process Archaeology’. For one week, keep a text file open on your desktop. Every time you perform one of these rote, unwritten procedures, you must immediately pause and jot down a single line. Don’t write the commands yet; just note the trigger and the purpose. The entry for my backup check would have been: ‘Friday PM – Verify WidgetApp backup checksums.’
At the week’s end, you will have a small, telling list. The next step is to exhume the command sequence from your memory and entomb it in a script. The goal isn’t necessarily full automation—sometimes the value is in the manual review—but it is formalization. Write the script. Place it in a known directory, like /usr/local/bin/. Give it a clear, descriptive name: verify-widgetapp-backup.
Now, the most crucial part: you must document the trigger. Open your crontab with crontab -e and, even if you don’t schedule the job, write the comment. Insert a line that reads: # Fridays at 16:00: /usr/local/bin/verify-widgetapp-backup. You are not yet asking the machine to remember for you; you are asking the system itself to hold the memory of this duty. You have transferred the knowledge from the volatile storage of your mind to the non-volatile storage of your configuration management. The next person who looks at that crontab, perhaps during an emergency, will see the entirety of the system’s heartbeat, not just the automated parts.
This act is a small victory against the fragility of institutional memory. It turns a personal habit into a shared, documented procedure. The unwritten cron job is a silent liability, a task that vanishes when you go on vacation or move on to another role. By writing its hymn—by giving it a name, a script, and a place in the documentation—you are not just automating a task. You are performing the careful, unglamorous work of making a system truly self-documenting, one recovered ritual at a time.
Notes & further reading
A few pages I came back to while writing this: