What Is a Cron Job? A Clear Beginner's Guide

By CronHub Tools · Updated 2026-08-04

A cron job is a command or script that your computer runs automatically on a schedule you define. Instead of logging in at 3 a.m. to back up a database, you tell the system to do it for you — every night, forever, without a single reminder. That is the whole idea of cron: set it once, and the task keeps running on time.

If you manage a Linux server, a Raspberry Pi, or a web host, you will meet cron sooner or later. This guide explains what a cron job is, how the cron daemon works, and how to read a real cron job example — all without jargon.

What Is a Cron Job, Exactly?

A cron job is a scheduled task on Unix-like systems (Linux, macOS, BSD). Each job pairs a time schedule with a command. When the clock matches the schedule, the system executes the command.

The name comes from Chronos, the Greek word for time. In practice, people use "cron" to mean three related things:

• cron — the background service that keeps time and runs jobs
• cron job — a single scheduled task (one schedule + one command)
• crontab — the file that lists your cron jobs ("cron table")

So when someone asks "what does cron do?", the short answer is: it watches the clock and runs your commands at the right moment.

How the Cron Daemon Works

The engine behind all of this is the cron daemon, a program usually named cron or crond. A daemon is simply a process that runs quietly in the background. The cron daemon wakes up once a minute, checks every user's crontab, and runs any job whose schedule matches the current time.

You can confirm it is running with:

systemctl status cron      # Debian/Ubuntu
systemctl status crond     # RHEL/CentOS/Fedora

Because the cron scheduler checks every minute, the smallest interval you can schedule with standard cron is once per minute. If you need sub-minute timing, cron is the wrong tool.

Anatomy of a Cron Job

Every cron job lives on one line with two parts: five time fields, then the command to run.

* * * * * /path/to/command
│ │ │ │ │
│ │ │ │ └── Day of week (0–7, both 0 and 7 = Sunday)
│ │ │ └──── Month (1–12)
│ │ └────── Day of month (1–31)
│ └──────── Hour (0–23)
└────────── Minute (0–59)

An asterisk (*) means "every value." Here is a real cron job example that runs a backup script every day at 2:30 a.m.:

30 2 * * * /home/alex/scripts/backup.sh

Read the fields in order: minute 30, hour 2, every day of the month, every month, every day of the week. The command after the fields is exactly what the shell would run if you typed it yourself.

Where Cron Jobs Are Stored

Cron jobs are not scattered randomly. They live in a few predictable places:

• User crontabs — each user has a personal crontab, edited with crontab -e
• System crontab — /etc/crontab, which adds a username field
• Drop-in directories — /etc/cron.d/, plus /etc/cron.daily/, cron.weekly/, and cron.hourly/ for scripts

To see your own jobs, run:

crontab -l

To add or change them, run crontab -e. The daemon picks up your changes automatically — no restart required.

Common Uses for Cron Jobs

Cron shines at any repetitive, time-based chore. Typical jobs include:

• Backups — dump a database or sync files every night
• Log rotation and cleanup — delete temporary files weekly
• Reports — email a sales summary each morning
• Cache warming — rebuild caches every few minutes
• Health checks — ping a service and alert if it is down
• Web app tasks — send reminder emails or process queues

If a task should happen on a clock, cron is usually the simplest answer.

Worth knowing: cron handles recurring schedules. For a one-time task ("run this once at 5 p.m."), the traditional companion tool is at, and modern systemd distros offer timers as a richer alternative. On macOS, cron still works, but Apple's native scheduler is launchd. For everyday server automation, though, cron remains the lingua franca — every tutorial, hosting panel, and CI system speaks it.

Common Mistakes Beginners Make

Cron is reliable, but it trips up newcomers in predictable ways. Watch for these:

1. Assuming your normal PATH exists. Cron runs with a minimal environment. Always use absolute paths, like /usr/bin/python3 instead of python3.
2. Forgetting the final newline. A crontab file must end with a newline, or the last job may be ignored on some systems. Editing with crontab -e handles this for you.
3. Swallowing output. By default, cron emails any output to the local user. Redirect it to a log so you can debug later: >> /var/log/myjob.log 2>&1.
4. Confusing day-of-month and day-of-week. If you set both, cron runs when either matches, which surprises many people.
5. Testing the schedule, not the command. Run the command manually first to be sure it works before you automate it.

Best Practices for Reliable Cron Jobs

A few habits keep your cron jobs dependable:

• Use absolute paths for every command and file.
• Send output to a log file and review it.
• Add a lock (flock) if a job must not overlap with a previous run.
• Keep scripts idempotent — safe to run twice without harm.
• Monitor important jobs so a silent failure does not go unnoticed.

Conclusion

A cron job is simply a scheduled command: five time fields plus something to run, managed by the cron daemon and stored in your crontab. Once you can read the five fields and remember to use absolute paths, cron becomes one of the most useful tools on any Linux system.

Ready to write your first one? Open your crontab with crontab -e, add a schedule, and let the cron scheduler do the rest. Explore our other guides below to master cron syntax and build jobs that never miss a beat.

Frequently Asked Questions

Related guides

References

• man7.org — crontab(5) manual page — authoritative field reference
• Ubuntu Community Help Wiki — CronHowto — beginner-friendly official docs
• crontab.guru — interactive schedule expression tester