What a cron job is, when you have just inherited one
A cron job is a line in a file that says "run this command at these times". A daemon reads those files, watches the clock, and launches the command. That is the whole idea, and it has not changed in forty years.
Almost nobody learns this from a blank page. You take over a site, or a server, or a client, and there is already a file with six lines in it, written by somebody who has left, and your actual question is not what cron is. It is whether these six lines still need to exist.
The list that matters is what cron does not do
Every expectation people have of cron that turns out to be false comes from this list. Read it as a set of features you have to build yourself if you want them.
| It does not | What happens instead |
|---|---|
| Retry a failed job | The failure is final until the next scheduled time |
| Keep a history of runs | The system log records that a command was launched, and nothing about the outcome |
| Wait for the previous run to finish | It starts a second copy on top of the first |
| Understand dependencies between jobs | Two jobs at 03:00 run at 03:00, in whatever order the machine feels like |
| Catch up on a missed schedule | A machine that was off at 03:00 simply did not run the 03:00 job |
| Tell anyone when something breaks | Output is mailed to a local address that usually goes nowhere |
| Care whether the command exists | A typo in a path is launched, fails instantly, and logs the same line as a success |
None of that is a defect. Cron is a timer, and it does the timer job with extraordinary reliability. The defect appears when a scheduled task is treated as a managed job, which is what happens by default because nothing about the interface suggests otherwise.
The row worth dwelling on is the last. Cron reports success on launching, not on completing. This is why "check the cron log" is such a persistent piece of bad advice: the log tells you the daemon tried, which is a genuinely different claim from the job having worked.
Five questions to ask a job you did not write
Take each line and answer these before deciding anything. Written down, they become the maintenance documentation nobody handed you.
What does it actually do? Follow the command to the script and read it. This is not always short, and it is not optional: an entry called cleanup.sh has, in real client work, turned out to delete files older than thirty days from a directory that had since become the media library.
What breaks if it does not run for a week? This is the question that ranks everything else. A cache warmer: nothing, the site is slightly slower. A backup: you find out in the worst possible circumstances. An invoice run: the client's revenue is late. The answer decides how much effort the job deserves.
What breaks if it runs twice? Some jobs are safe to repeat and some send the same email again, charge the same card again, or double a counter. If the answer is "something visible to a customer", the job needs a lock before it needs anything else.
Where does its output go? Trace it. In the majority of inherited crontabs the answer is a mail spool nobody has opened, or nothing at all.
When did it last succeed? Not "when did it last run". If you cannot answer this from evidence, the job is unmonitored regardless of what any dashboard says.
Dating the thing
Archaeology is quick and it changes the conversation with the client, because "this was written in 2019 and last touched by a developer you no longer work with" is a fact rather than an opinion.
stat /var/spool/cron/crontabs/$USER # when the crontab itself last changed
stat /usr/local/bin/whatever.sh # when the script last changed
git log -1 --format='%ai %an' -- path/to/script.sh # if it is in a repository at allThen look for evidence of the job actually working. A log file that stops abruptly two years ago, an output directory whose newest file is from a previous hosting provider, a database table with a last_run_at column that has not moved: any of those settles the question faster than reading the code.
The pattern to watch for is a job that has been failing since a migration. The command still launches every night, the daemon still logs it, and the thing it produces stopped appearing when the paths changed. Nobody noticed because nothing announced it, and the crontab looks perfectly healthy.
Keep, replace, or disable
Three outcomes, and one rule about the third.
Keep means you understood it, it still matters, and you are now going to add the things cron does not provide: an absolute path to the interpreter, a redirect for the output, a lock if it can overlap, and something outside the machine that expects to hear from it.
Replace means the work belongs in the application rather than in a shell script on a server, where it can be tested, versioned and read by the next person. A single crontab entry that hands control to the framework's own scheduler is usually the destination, and it also settles the question of which cron dialect the server speaks, which is less settled than it looks.
Disable is not delete. Comment the line, and put the date and your initials on the comment:
# 2027-02-04 disabled pending confirmation with client, no evidence of a successful run since 2024
# 0 3 * * * /usr/local/bin/legacy-export.shThe reason is dull and it has been paid for many times. A job removed cleanly leaves no trace, so when something turns out to have depended on it three months later, there is nothing to find and nobody remembers. A commented line with a date is a two-second answer to a question that otherwise costs an afternoon.
What to hand to the next person
One file per client, one row per scheduled job: what it does, what it touches, how often, what happens if it stops, and how you would know. Five columns.
That document is worth more than the crontab, because the crontab describes the mechanism and the document describes the intent, and the intent is the part that gets lost. It is also the thing that makes the last column answerable, which it is not today for most inherited jobs: you cannot decide how to detect a failure until you have written down what failure means for that particular job.
Then read the expressions themselves once, carefully, because an inherited crontab has usually accumulated at least one schedule that does not do what its author believed: the step operator and the day-of-week OR account for most of them.
