Cron Jobs Explained: Syntax, Real Schedules and the Mistakes That Break Them

A nightly backup has quietly not run for three weeks. The script works perfectly when run by hand. The cron entry looks right. This is the most common cron story, and it almost always comes down to a handful of predictable mistakes. Once you know them, cron is one of the simplest and most reliable tools in operations.

To show precisely when each schedule fires, we calculated the next run times with the croniter 6.2 Python library, starting from Monday 9 November 2026 at 10:07. We did not run a cron daemon for this article; the crontab and shell snippets are standard examples, not output from our machine.

What is cron?

Cron is a time-based job scheduler found on Linux, macOS and other Unix-like systems. A background service, the cron daemon, wakes up every minute, checks each user’s schedule table, called a crontab, and runs any command whose time matches. The same five-field expression format is also used by Kubernetes CronJobs, GitHub Actions schedules and many cloud schedulers.

The five fields

┌───────── minute        (0-59)
│ ┌─────── hour          (0-23)
│ │ ┌───── day of month  (1-31)
│ │ │ ┌─── month         (1-12 or JAN-DEC)
│ │ │ │ ┌─ day of week   (0-6, Sunday = 0, or SUN-SAT)
│ │ │ │ │
* * * * *  command to run

Many systems also accept 7 for Sunday. Names such as MON-FRI work in most implementations; our validator accepted 0 9 * * MON-FRI and rejected 61 * * * *, since minutes stop at 59.

Operators

Steps count from the start of the range. */15 in the minute field means minutes 0, 15, 30 and 45, not “15 minutes after the last run”. Extra symbols such as L (last), W (weekday) and # (nth weekday) come from Quartz and some cloud schedulers; standard Linux cron does not support them.

Verified examples

Here are common expressions with the next three run times we calculated from Monday 09 Nov 10:07:

Two details are worth noticing. “Weekdays at 09:30” skipped Monday 9 November, because 09:30 had already passed at 10:07. And the “31st” job skipped November and February entirely, because those months have no 31st. Cron does not move it to the last day of the month. For a true month-end job, run on days 28 to 31 and let the script check whether tomorrow is the 1st.

The day-of-month and day-of-week trap

Suppose you want a job on the 1st of the month, but only if it is a Monday, and you write 0 9 1 * 1. Here is what it actually does:

0 9 1 * 1  ->  Mon 16 Nov, Mon 23 Nov, Mon 30 Nov, Tue 01 Dec, Mon 07 Dec, Mon 14 Dec

It runs on every Monday and on the 1st of every month. When both day fields are restricted, traditional cron treats them as OR. This surprises almost everyone. With croniter’s AND mode switched on, the same expression gave Mon 01 Feb 2027, Mon 01 Mar 2027 and Mon 01 Nov 2027, which is probably what was meant, but standard cron does not behave that way. The reliable approach is to schedule the wider condition and check the other inside the script, for example run every Monday and exit unless the date is 1 to 7 for “first Monday of the month”.

@daily and other shortcuts

Shortcuts are readable, but they all fire at midnight. If many servers or jobs use @daily, they all start at the same moment, which can overload a shared database or API. Spreading start times, such as 17 2 * * *, avoids that spike.

Editing a crontab

crontab -e     # edit your crontab
crontab -l     # list it
crontab -r     # remove it entirely (careful!)

Each line is one job. Lines starting with # are comments; use them to say what each job does and who owns it. crontab -r sits right next to -e on the keyboard and deletes everything without asking, so keep a copy of important crontabs in version control. System-wide jobs live in /etc/crontab and /etc/cron.d/, where lines include an extra user field before the command.

Why jobs work by hand but not in cron

Cron runs commands with a very small environment, not your login shell. The usual culprits:

• PATH: cron’s PATH is often just /usr/bin:/bin, so tools in /usr/local/bin or a virtual environment are not found. Use full paths, such as /usr/bin/python3 or the venv’s own Python.
• Working directory: jobs usually start in the user’s home directory. Relative paths like ./data/report.csv point to the wrong place. cd first or use absolute paths.
• Environment variables: variables from your .bashrc are not loaded. Set them in the crontab or in a wrapper script; see our environment variables guide.
• Shell: cron uses /bin/sh by default, not bash, so bash-only syntax fails.
• The percent sign: in a crontab line, % means a newline and must be escaped as \%. This breaks date +%Y-%m-%d in many first attempts.
• Permissions: the job runs as the crontab’s owner, who may not be able to read the files you expect.

# A safer crontab entry (example, not run for this article)
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=ops@example.com

17 2 * * * cd /srv/shop && ./venv/bin/python backup.py >> /var/log/shop/backup.log 2>&1

Logging and alerts

By default, cron emails any output to the job’s owner, which on most servers goes nowhere. Redirect output to a log file, as above, with 2>&1 so errors are captured too. Inside the script, use proper logging with timestamps, as in our Python logging guide. Most importantly, alert on silence: a failed job may produce an error, but a job that never runs produces nothing. “Dead man’s switch” monitors, where the job pings a URL on success and an alert fires if the ping does not arrive, catch both.

Overlapping runs

If a job scheduled every 5 minutes sometimes takes 7, two copies will run at once, which can corrupt files or double-process data. Wrap the command with flock, for example flock -n /tmp/sync.lock ./sync.sh, so a second copy exits immediately if the first still holds the lock. Making jobs idempotent, so running them twice is harmless, gives you a second layer of safety, and an upsert is a common way to achieve that for database writes.

Time zones and daylight saving

Cron uses the server’s time zone, which on cloud servers is usually UTC. A job set for 09:00 may fire at 14:30 local time in India. In regions with daylight saving time, a job scheduled between 02:00 and 03:00 can be skipped or run twice on the days the clocks change. Prefer UTC on servers, avoid scheduling important jobs in the changeover hour, and document the time zone next to each job. Some cron implementations support a CRON_TZ variable; check your system before relying on it.

Cron in modern platforms

• Kubernetes CronJobs use the same five fields and add a concurrencyPolicy setting to prevent overlaps.
• GitHub Actions supports on: schedule with cron syntax, always in UTC, and scheduled runs can be delayed at busy times. See our GitHub Actions guide.
• systemd timers on Linux offer logging, dependencies and catch-up of missed runs.
• Cloud schedulers from AWS, Google Cloud and Azure trigger functions or containers without a server to manage.

Whatever runs the schedule, the habits are the same: absolute paths, captured output, overlap protection, alerts on missed runs and clear ownership.

Final thoughts

Cron’s five fields are easy to learn and easy to misread. Check every new expression with a calculator or library before trusting it, watch out for the day-of-month OR day-of-week rule and months without a 31st, and write jobs that use absolute paths, log their output and cannot overlap. Then add an alert for the job that silently stops running, because that is the failure you would otherwise discover weeks later.

Frequently asked questions

Keep learning