What is a cron schedule?

What it is, in plain words

A cron schedule is an alarm clock for software. You set the times, and at each one the computer starts a job: build the weekly report, publish the next post, back up the sheet.

The name comes from cron, the scheduler built into Linux servers, and from the short format it uses to write times down. A cron expression has five positions:

Position	Meaning	0 9 * * 1-5
1	Minute	0
2	Hour	9
3	Day of month	any
4	Month	any
5	Day of week	Monday to Friday

So 0 9 * * 1-5 reads “at 9 on weekdays”. You do not need to write these. Automation tools show a form with “every day at 9” and turn it into the same thing. Windows has its own version, the Task Scheduler, which is what my own jobs run on.

A concrete example

A small business wants yesterday’s orders summarised in a sheet every morning before the team starts. The freelancer sets a schedule for 7 every day. At 7 the job wakes up, reads the orders, writes the summary and stops. Nobody presses anything.

That is the whole idea, and it works well. The trouble is what the alarm clock does not promise.

What “runs daily at 9” really means

An alarm clock rings at 9. It does not promise that you get up. A schedule is the same: it promises that the computer will try to start the job at 9, if it can. Everything else is up to the setup.

My own scheduled jobs have shown me each of the gaps:

• The machine has to be awake. My jobs run on a laptop that drops into a low-power mode when the screen turns off. On one evening a job due at 20 started 38 minutes late; the next morning, one ran three hours late; one due at 23 never ran at all.
• Awake is not always enough. One night an update restarted the machine at about 01. It stayed on, but nobody logged in until morning. Three jobs due at 02, 04 and 06 did not run, and the scheduler simply moved each one to the next day. They were set to “run as soon as possible after a missed start”, and that did not help: the machine had not been off, it had been waiting for a login. I published the five waiting items by hand that morning, a few hours before they would have expired.
• The schedule is only as right as the last change to it. Once I paused one job for a night and set a second job to switch it back on at 07. The paused job was due at 06. It missed that day.
• “Started” is not “finished”. A schedule starts the job. Whether the job succeeds is a separate question, and a job that fails quietly looks, from the schedule’s side, exactly like one that worked. The field note on sleep mode shows a night where both kinds of silence happened together.

Two more points apply to everyone, not just laptops: whose clock (a schedule on a server may run in a different time zone from yours, or from your customers’) and what happens when a run overlaps the next one.

Why it matters when you hire someone

If you do not know the gaps above, you will accept an automation because it ran when the freelancer clicked Run, and find out weeks later that the 9 job has been skipping days. Nobody lied. “Runs daily at 9” was simply never tested under the conditions it will meet.

It also decides where the automation should live. A schedule on a hosted platform or an always-on server avoids the sleep and login problems. A schedule on someone’s personal computer inherits all of them.

What to ask the freelancer

The last question is the one that catches most problems. A missing run produces no error, so the alert has to notice the absence. That is what heartbeat monitoring does, and the acceptance checklist for unattended automations includes a test that puts the machine to sleep across a scheduled time before you pay.