Cron Syntax Explained: */15 * * * * and Other Examples

By Álvaro G.V. · Updated October 16, 2026

Cron is the standard Unix scheduler — but its five-field syntax trips up developers every time they need to schedule something non-trivial. This guide walks through every field, every special character, and the common patterns you'll actually reach for.

Cron Expression Format: Quick Reference

A cron expression is five fields separated by spaces, always in this order: minute hour day-of-month month day-of-week. Each field takes a number, * (every value), a list (1,15), a range (1-5) or a step (*/15). The job runs whenever the current time matches every field.

Build and test expressions as you go with the visual cron expression builder, or jump straight to the copy-paste cron examples. Cron schedules run on the server clock, so the Unix timestamp converter is handy when you need to check when a job actually fired.

What Is a Cron Expression?

A cron expression is a string of five fields separated by spaces that defines a schedule for recurring jobs. Each field represents a unit of time:

┌───────────── minute (0–59)
│ ┌───────────── hour (0–23)
│ │ ┌───────────── day of month (1–31)
│ │ │ ┌───────────── month (1–12)
│ │ │ │ ┌───────────── day of week (0–6, Sunday=0)
│ │ │ │ │
* * * * *

The cron daemon reads the crontab file and wakes up every minute to check which jobs match the current time. If all five fields match, the command runs.

Special Characters

* — Any value

Matches every value in the field. * * * * * runs every minute of every hour of every day.

/ — Step values

Defines an interval. */15 in the minute field means "every 15 minutes". 2/3 means "starting at 2, every 3 steps" — so 2, 5, 8, 11, ...

- — Ranges

Defines a continuous range. 9-17 in the hour field means hours 9 through 17 inclusive. 1-5 in the day-of-week field means Monday through Friday.

, — Lists

Specifies multiple individual values. 0,15,30,45 in the minute field runs at minutes 0, 15, 30, and 45. MON,WED,FRI in the day-of-week field runs on those three days.

Common Examples

Extended Cron: @shortcuts

Most modern cron implementations support shorthand strings that replace the five-field syntax:

Common Cron Mistakes

1. Assuming cron runs in your local time zone

A cron expression has no time zone of its own; the scheduler decides. Classic cron uses the time zone of the machine it runs on, and cloud VMs and containers are usually set to UTC. A job written as 0 9 * * * on a UTC server fires at 09:00 UTC, which is 11:00 in Madrid in summer. Check with timedatectl or date. Cronie (the default on Fedora and RHEL) supports a CRON_TZ=Europe/Madrid line in the crontab; GitHub Actions schedules are always UTC; Kubernetes CronJobs use the controller's time zone unless you set spec.timeZone; AWS EventBridge rules are UTC (EventBridge Scheduler accepts a time zone).

Daylight saving time adds a second trap: in a zone that observes it, a job scheduled between 01:00 and 03:00 can be skipped or run twice on the change-over nights, depending on the cron implementation. Schedule critical jobs in UTC or outside that window.

2. Expecting AND when both day fields are set

When both day-of-month and day-of-week are restricted (neither is *), standard cron runs the job when either matches. 0 9 13 * 5 does not mean "Friday the 13th"; it runs on every 13th of the month and every Friday. If one of the two fields is *, only the other one applies, which is what you usually want. To get a real AND, restrict one field in cron and test the other in the command:

# 09:00 on Friday the 13th only
0 9 13 * * [ "$(date +\%u)" = 5 ] && /usr/local/bin/job.sh

Quartz and AWS EventBridge avoid the ambiguity by requiring ? in one of the two day fields.

3. Expecting */n to be an exact interval

A step restarts at the beginning of its field every time the field rolls over, so it only produces an even interval when n divides the range exactly. */7 in the minute field runs at :00, :07 … :49, :56 and then :00 again, a 4-minute gap. */25 gives :00, :25, :50 and then a 10-minute gap. In the hour field, */5 runs at 00, 05, 10, 15 and 20, then 00 the next day, a 4-hour gap. Use divisors of 60 for minutes (*/5, */10, */15, */20, */30) and divisors of 24 for hours (*/4, */6, */8, */12). An interval that does not fit, such as every 90 minutes, needs two lines:

0  0-21/3 * * *  /usr/local/bin/job.sh   # 00:00, 03:00 … 21:00
30 1-22/3 * * *  /usr/local/bin/job.sh   # 01:30, 04:30 … 22:30

The step also counts from the clock, not from when you saved the crontab or deployed: */15 always means :00, :15, :30 and :45.

4. Mixing up 5-field, 6-field and 7-field formats

Not every "cron" is Unix cron. Copying an expression between systems without checking the field count is one of the most common scheduling bugs:

A 6-field expression pasted into a crontab is not rejected: cron reads the first five fields as the schedule and treats the sixth as the start of the command, so 0 0 4 * * * becomes "midnight on the 4th of every month" running a command that starts with *. Going the other way, Spring and Quartz reject a 5-field expression outright. The 0 4 * * * page shows this schedule written out for every platform.

5. Forgetting to escape % in crontab

In a crontab command, an unescaped % is turned into a newline, and everything after the first one is sent to the command's standard input. A date format string is the usual victim:

# Broken: the command is cut off at the first %
0 2 * * * tar czf /backup/site-$(date +%F).tar.gz /var/www

# Fixed: escape every % with a backslash
0 2 * * * tar czf /backup/site-$(date +\%F).tar.gz /var/www

The rule applies to the command field of crontab files (crontab -e, /etc/crontab, /etc/cron.d/), not to scripts that cron calls, so moving anything non-trivial into a script avoids the problem entirely.

6. Leaving * in the minute field

* 2 * * * does not mean "at 2 AM"; it means every minute from 02:00 to 02:59, 60 runs. Always set the minute: 0 2 * * * runs once.

Validation Tips

• Always test before deploying. Paste the expression into the Cron Builder and check the next run times. An expression like 0 0 31 * * only runs on months that have a 31st day — February, April, June, September, and November will silently skip it.
• Use absolute paths. Cron runs with a stripped-down environment. Replace python3 script.py with /usr/bin/python3 /home/user/script.py.
• Make scripts executable. If cron calls a script directly, it needs the execute bit (chmod +x script.sh, or 755). See Linux file permissions explained if the octal notation is unfamiliar.

Build and Validate Cron Expressions Online

If you want to visually build a cron expression and see a plain-English description, the Cron Builder on DevEssentials generates valid cron syntax from a GUI and explains any expression you paste in. No login, 100% client-side.

Looking for a ready-made schedule? See copy-paste cron examples for every 5 minutes, hourly, daily, weekdays and more.

Want one expression explained in depth? See common cron expressions explained, with pages for */15 * * * *, 0 0 * * *, 0 */6 * * * and more, including Quartz and AWS equivalents.

Need to build a cron expression? Use the visual Cron Builder →