Cron Job

Some of the work a server has to do isn't triggered by anyone. Totalling yesterday's usage, deleting temporary files older than a month, generating invoices on the first of the month — nobody is pressing a button for any of it. Before schedulers, that meant a person had to remember the time, log in, and run the command themselves.

An operations engineer's day used to start with an alarm clock. Totals had to run when traffic was lowest, so someone woke at three, connected to the server, typed one line, checked that the output looked right, and went back to bed. The arrangement only worked as long as that person stayed in place. When they took a week off, that week's totals simply didn't exist, and when a colleague covering for them mistyped the command, a day's numbers went wrong with nobody noticing.

The cause was structural rather than a question of diligence: the promise to run the same command at the same hour every day was stored in a human memory. A cron job hands that promise to the server — the program that receives requests and returns responses, and that stays switched on whether or not anyone is watching. It can read the clock and run the command instead. Writing down a time and a command becomes the entire human contribution.

You register a line pairing a time with a command, and a scheduler running on the server checks the clock every minute and fires that command the moment the conditions match.

The time is written as five fields, always in this order.

1. Minute — 0 through 59.
2. Hour — 0 through 23.
3. Day of month — which date in the month.
4. Month — 1 through 12.
5. Day of week — 0 is Sunday.

Each field holds either a number or an asterisk, which means "any value here." So 0 3 * * * means three in the morning every day regardless of date or weekday, */10 * * * * means every ten minutes, and 0 9 1 * * means nine in the morning on the first of each month. The notation looks like a cipher at first and becomes readable once the order of the five fields is memorized.

Three things tend to bite after registration.

1. Time zones. If the server clock runs on coordinated universal time, 0 3 * * * fires at noon in Seoul. This is how a heavy nightly aggregation ends up running at the busiest hour of the day.
2. Overlap. A job scheduled every ten minutes that starts taking twelve means the next run begins before the previous one has finished. Two runs touching the same data can add the same amount twice. A lock that skips the run while another is still going prevents it, and the skipped run shows up in the log so the growth in duration doesn't stay hidden.
3. Failure. The scheduler runs the command and never looks at the result. If the job dies halfway, the next scheduled time starts fresh as though nothing happened, and the failed run stays missing forever. Logging each run and alerting on failure is a separate thing you have to build.

Work that needs to happen once at a fixed time, and that nobody is sitting around waiting for, lands here.

• Aggregation and billing — gathering yesterday's records into the numbers people look at today, or calculating last month's usage on the first to produce an invoice.
• Cleanup — deleting temporary files past thirty days, expiring old invitation links. Things that accumulate slowly enough that once a day is plenty.
• Synchronization — pulling data from an outside service to match your own copy. Exchange rates or plan details, where being a few hours stale costs nothing.
• Scheduled sending — picking everyone whose trial ends in three days and emailing them in one pass. The selection is a query against a date, which is exactly the kind of question that only makes sense to ask once a day.

At Pagedeck a job at four in the morning totals document usage per team and refreshes the numbers on the admin screen. Calculating that on the fly would add several seconds every time someone opened the page; instead it is computed once a night and merely read during the day.

Work created by someone pressing a button goes elsewhere. Exporting a document to PDF has to start the instant it's requested, so it becomes a background job, and when many such requests arrive at once a message queue lines them up in order.

"That aggregation runs on a cron at four every morning."

Nobody triggers it by hand; it fires on a schedule.

"Last night's cron failed and no alert fired, so we only found out this morning."

Nothing was watching the outcome, and a day of results passed by empty.

"I think this should be event-driven rather than a cron."

A proposal to handle the work the moment something happens instead of waiting for a clock time.

At Pagedeck the subject usually comes up when a number looks wrong. Mia mentions that usage on the admin screen is identical to yesterday's, and Theo opens the run log for the overnight job to see whether it stopped partway. If it did, he runs it once by hand to fill in the missing day and investigates the cause separately.

The most common assumption is that a job definitely runs at the time written down. Since the whole mechanism watches a clock, that expectation is easy to form. In practice the server has to be alive at that instant. If a deployment or a machine restart spans the moment, that run never happens at all. Work like a monthly billing run, where one missed cycle is a real problem, needs a record of which cycles completed and a way to replay a missing one later.

The other belief is that a job set up once needs no further attention. Registration is one line, but the data behind it keeps growing. An aggregation that took three minutes at launch takes twenty-five six months later, and if it was scheduled every ten minutes it has been overlapping with itself since somewhere in between. Recording how long each run took, right alongside the schedule, makes that drift visible. When you can see three minutes become five and then twelve, you get to widen the interval or split the work before anything breaks.