What is a cron job in simple terms?

A cron job is a task your computer runs for you on a schedule — one line in a file that says "run this command at these times". The cron daemon wakes up once a minute, checks the schedule, and runs whatever is due. Backups at 2:30 every night, a report every Monday morning, a cache clear every hour: all classic cron jobs.

What is the difference between cron, crontab, and a cron job?

Cron is the daemon — the background service that does the running. A crontab is the file that lists the schedule — one job per line. A cron job is one single scheduled task: one line in a crontab. So cron runs cron jobs listed in crontabs.

How do I create a cron job?

Run crontab -e to edit your personal crontab, add one line with five time fields followed by the command, save, and exit. For example, 30 2 * * * /usr/local/bin/backup.sh runs the backup script every day at 02:30. Always use absolute paths for the command and its files, and redirect output to a log file so you can see whether it ran.

Why did my cron job not run?

The usual suspects, in order: the cron daemon is not running; the command relied on PATH or environment variables that do not exist in cron's minimal environment (use absolute paths); a typo in the schedule; the script needs a shell profile that cron never loads; or the job did run but its output went to email nobody reads. Redirect output to a log file so failures are not silent.

Can cron run a job every second?

No — the smallest cron unit is one minute. For sub-minute scheduling, run a script every minute that loops internally with sleep, or use a proper scheduler: systemd timers support sub-minute accuracy, as do most job queues.

What do @daily, @hourly, and @reboot mean in a crontab?

They are shorthand nicknames that replace the five time fields: @daily (or @midnight) means 0 0 * * *, @hourly means 0 * * * *, @weekly means 0 0 * * 0, @monthly means 0 0 1 * *, @yearly (or @annually) means 0 0 1 1 *. @reboot is special: it runs once when the daemon starts, which normally means when the machine boots.

What happens if the computer is off when a cron job is due?

The run is simply skipped — cron does not catch up later. It is a pattern matcher, not a queue: it checks "is the time right now?" once a minute, and a missed minute is gone. If the machine is a laptop that sleeps, use anacron or a systemd timer instead; both can run a missed job after the machine wakes.

Is cron the same as Windows Task Scheduler?

It is the same idea on a different system: both run commands on a schedule without anyone at the keyboard. Windows Task Scheduler has a graphical interface and can wake a sleeping machine; cron is a text file and a daemon, and it skips runs while the machine is off. The concepts — schedule plus command, logging, permissions — transfer directly.

What Is a Cron Job? 7 Things Every Developer Should Know (With Examples)

November 5, 2026 · DevOps

Right now, on servers everywhere, backups are starting at 2:30 in the morning and caches are being cleared every hour — with nobody awake to press a button. The mechanism is a cron job. What is a cron job, how is it different from a crontab, and why do so many silently fail? This guide answers in 7 parts: definition, daemon and crontab, anatomy, where jobs live, a real example, the classic pitfalls, and when to use something else.

What is a cron job?

A cron job is a command or script that the cron scheduler runs automatically at times you choose. One line in a schedule file says "run this at these times", and the system takes care of the rest. The name comes from Chronos, the Greek word for time, and the idea is older than most developers using it: the first cron shipped in May 1975 at AT&T Bell Laboratories, and the Vixie cron most Linux systems use dates to 1987.

Cron is built for repetitive work: nightly backups, log rotation, weekly reports, cleaning up expired sessions. For a one-time task, cron is the wrong tool: Unix has the at command for "run this once, later". If it repeats, it is a cron job; if it happens once, it is not.

Illustration of a cron job: a clock with a calendar behind it and a small server rack, a robot arm handing a task envelope to the clock — A cron job is a task with a clock attached: the schedule decides when, the command decides what, and nobody has to be awake for either.

The two parts: the daemon and the crontab

Two pieces work together, and confusing them is the first beginner mistake. The cron daemon — usually just cron or crond — is a background service that starts at boot and wakes up once every minute. A crontab ("cron table") is a plain text file of schedules: each line is one job. The daemon reads the crontabs and starts whatever lines match the current minute.

So: cron is the service, crontab is the file, and a cron job is one line in that file. Each user can have their own crontab, edited with crontab -e, and its commands run as that user. There is also a system-wide crontab at /etc/crontab plus system schedules at /etc/cron.d/ — both editable only by administrators.

Illustration of the cron daemon: an alarm clock waking once a minute to check a long checklist and start the task that is due — The daemon's whole job is a loop: wake once a minute, check the schedule, run what is due, sleep again.

Anatomy of one cron job line

Every cron job is a single line: a schedule followed by a command. The schedule is five fields — minute, hour, day of month, month, day of week — and then the command to run:

# minute hour day-of-month month day-of-week  command
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

That line runs the backup daily at 02:30 and appends output to a log. A star means "every value", a comma makes a list (1,15), a dash makes a range (1-5, Monday to Friday), and a slash makes a step (*/15, every 15 minutes). Our cron expressions guide covers the full syntax field by field, including the two traps that bite everyone exactly once — so this guide does not repeat it.

There are also nicknames that replace the five fields: @daily is midnight every day, @hourly the top of every hour, @weekly midnight on Sunday, @monthly midnight on the 1st, and @yearly midnight on January 1st. And @reboot is the odd one out: it runs once when the daemon starts — in practice, when the machine boots.

Illustration of a cron job line: five small blocks for the schedule fields followed by a longer gear-shaped block for the command, read left to right — One line, two halves: five schedule fields on the left, the command on the right. Everything else is commentary.

Where cron jobs live

Not all crontabs are the same file, and picking the wrong one is a common source of "it works for me but not on the server":

Your personal crontab (crontab -e) — jobs run as you. This is where almost every developer's jobs belong.
The system crontab (/etc/crontab) — jobs for the whole machine, edited by root, with an extra username field before the command.
/etc/cron.d/ — system schedule files, one per package or service, each with the same username field. This is how installed software ships its own scheduled jobs.
/etc/cron.daily/, /etc/cron.hourly/, and friends — drop-in directories where any executable script is run daily or hourly. No crontab editing needed; just place the script.

Permissions are controlled by /etc/cron.allow and /etc/cron.deny: if cron.allow exists, only the users named in it may use cron; otherwise anyone not named in cron.deny may.

A real example: create a job, then prove it ran

A cron job you cannot see run is a cron job you cannot trust. Here is the smallest honest workflow: a daily backup job, written properly, and a check that it actually ran.

# Edit your crontab
crontab -e

# Add this line: backup every day at 02:30, logging everything
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# List what is scheduled, to confirm the line saved
crontab -l

Two details in that one line are doing real work. The absolute path matters because cron runs with a minimal environment — no aliases, no shell profile, and a tiny PATH — so backup.sh without a path would not be found. The log redirect matters because cron's default is to email any output to the crontab owner, and on most servers nobody reads that mail; without the redirect, a failed job fails silently.

To prove the schedule means what you think it means, I checked the matching rule against real calendar dates with a small script implementing the crontab(5) rule — minute, hour, and month must match, and at least one of the two day fields must match. The trap line 30 4 1,15 * 5 does not mean "the 1st and 15th, if they are Fridays": its next runs from November 5, 2026 are Friday November 6, Friday November 13, Sunday November 15, Friday November 20, Friday November 27, and Tuesday December 1 — Fridays and the 1st and 15th. The same check confirms */35 fires at :00 and :35 only, and 30 2 * * 1-5 runs Friday November 6, then skips the weekend to Monday November 9. Check the next runs before you trust the schedule; the OR trap has bitten everyone once.

Build the schedule visually: our free Cron Expression Generator turns plain English into a cron expression with a human-readable explanation — and our cron expressions guide explains every field, step, and trap in detail.

Why cron jobs fail: five classic pitfalls

Most cron jobs that "don't work" ran exactly as written — and the writing was wrong. These five account for nearly all of them:

The environment trap. Cron runs commands with SHELL=/bin/sh and almost no environment: no profile, no aliases, no PATH entries from your shell setup. A script that works in your terminal but fails in cron is almost always missing an absolute path or an environment variable. Our environment variables guide explains what a process inherits.
Overlapping runs. If a job takes longer than its interval, cron happily starts a second copy. A backup that runs 70 minutes on an hourly schedule will eventually have two copies fighting over the same files. Use a lock file (flock) for anything that must not overlap: 0 * * * * /usr/bin/flock -n /tmp/backup.lock /usr/local/bin/backup.sh.
Missed runs when the machine is off. Cron is a pattern matcher, not a queue: it checks the time once a minute, and a run whose minute passed while the machine slept is skipped — it never catches up. Laptops that sleep need anacron or a systemd timer, which can run a missed job after the machine wakes.
Silent failures. By default cron mails a job's output to its owner, and on most servers that mail goes nowhere. Redirect output to a log file (>> /var/log/job.log 2>&1) and set MAILTO to an address someone reads — or to empty (MAILTO="") if you are logging everything instead.
The schedule does not mean what you think. The day-of-month OR day-of-week trap, the */35 step quirk, and daylight saving: jobs in the "missing" hour when clocks jump forward never run, and jobs in the repeated hour when clocks fall back run twice.

Illustration of cron pitfalls: two identical task envelopes colliding at one door, a sleeping computer with its power light off, and an overflowing mailbox — The three silent killers: overlapping copies of the same job, a machine that was asleep at run time, and output nobody ever reads.

When cron is the wrong tool

Cron has survived fifty years because it is simple, but simple is not always right:

You need reliability guarantees. Cron does not retry a failed job, does not know if a job succeeded, and does not run missed jobs. A message queue — with acknowledgements, retries, and a dead-letter queue — is the right shape when a missed or failed task costs real money.
The work is event-driven, not time-driven. "Run when a payment arrives" is not a schedule. A webhook or an event trigger answers that; polling with cron every minute is a workaround, not a design.
You need sub-minute precision or dependencies. Cron's smallest unit is one minute, and it knows nothing about "run B only after A succeeds". Systemd timers handle sub-minute accuracy and ordering; job queues handle dependencies.
The schedule lives in the cloud. A serverless function on a cloud schedule (for example AWS EventBridge) keeps working when your server is off, and its dialect is close enough to cron that the same five-field thinking transfers — though EventBridge numbers Sunday as 1, not 0.

The honest test: if the job is a simple recurring command on a machine that stays on, cron is still the best tool for it — it has been since 1975. If the job needs retries, ordering, or a guarantee it ran, graduate to a queue or scheduler built for the job.

A cron job is one line: a schedule plus a command, checked once a minute by a daemon doing exactly that since 1975. If you can read the five fields, write the command with absolute paths, log its output, and guard it against overlapping runs, you understand the pattern behind nearly every automated task on a Unix system. For deeper reference, see Wikipedia's cron article and the crontab(5) manual page.

Frequently asked questions

What is a cron job in simple terms?: A cron job is a task your computer runs for you on a schedule — one line in a file that says "run this command at these times". The cron daemon wakes up once a minute, checks the schedule, and runs whatever is due. Backups at 2:30 every night, a report every Monday morning, a cache clear every hour: all classic cron jobs.
What is the difference between cron, crontab, and a cron job?: Cron is the daemon — the background service that does the running. A crontab is the file that lists the schedule — one job per line. A cron job is one single scheduled task: one line in a crontab. So cron runs cron jobs listed in crontabs.
How do I create a cron job?: Run crontab -e to edit your personal crontab, add one line with five time fields followed by the command, save, and exit. For example, 30 2 * * * /usr/local/bin/backup.sh runs the backup script every day at 02:30. Always use absolute paths for the command and its files, and redirect output to a log file so you can see whether it ran.
Why did my cron job not run?: The usual suspects, in order: the cron daemon is not running; the command relied on PATH or environment variables that do not exist in cron's minimal environment (use absolute paths); a typo in the schedule; the script needs a shell profile that cron never loads; or the job did run but its output went to email nobody reads. Redirect output to a log file so failures are not silent.
Can cron run a job every second?: No — the smallest cron unit is one minute. For sub-minute scheduling, run a script every minute that loops internally with sleep, or use a proper scheduler: systemd timers support sub-minute accuracy, as do most job queues.
What do @daily, @hourly, and @reboot mean in a crontab?: They are shorthand nicknames that replace the five time fields: @daily (or @midnight) means 0 0 * * *, @hourly means 0 * * * *, @weekly means 0 0 * * 0, @monthly means 0 0 1 * *, @yearly (or @annually) means 0 0 1 1 *. @reboot is special: it runs once when the daemon starts, which normally means when the machine boots.
What happens if the computer is off when a cron job is due?: The run is simply skipped — cron does not catch up later. It is a pattern matcher, not a queue: it checks "is the time right now?" once a minute, and a missed minute is gone. If the machine is a laptop that sleeps, use anacron or a systemd timer instead; both can run a missed job after the machine wakes.
Is cron the same as Windows Task Scheduler?: It is the same idea on a different system: both run commands on a schedule without anyone at the keyboard. Windows Task Scheduler has a graphical interface and can wake a sleeping machine; cron is a text file and a daemon, and it skips runs while the machine is off. The concepts — schedule plus command, logging, permissions — transfer directly.