Cron Expressions Explained: Fields, Examples and Pitfalls

Questo contenuto è in inglese.

Cron is the scheduling system behind countless automated tasks, from nightly backups to weekly reports. A cron expression looks compact but packs several rules into five fields, and small slips can make a job run far more or less often than intended. This guide walks through the syntax, worked examples and the mistakes to avoid.

Di Valtrinity. Aggiornato il 18 ottobre 2026.

What a cron expression does

A cron expression describes a repeating schedule. Cron daemons on Linux and Unix systems read these expressions from crontab files, and many cloud platforms, CI services and task runners use the same format. The scheduler checks the expressions every minute to see whether any job is due, then runs the associated command.

The standard format has five fields separated by spaces: minute, hour, day of month, month and day of week. Some systems add a sixth field for seconds, and Quartz-based Java schedulers add a seventh for years. Check which flavour your platform uses before copying an expression from elsewhere.

The five fields and their ranges

Each field accepts a single value, a list separated by commas, a range with a hyphen, or a step using a slash. So 1,15 means the first and the fifteenth, 9-17 means every value from nine to seventeen, and */10 means every tenth value starting from the lowest allowed.

Minute: 0 to 59
Hour: 0 to 23, using the 24-hour clock
Day of month: 1 to 31
Month: 1 to 12, or names such as jan and dec in many implementations
Day of week: 0 to 6, where 0 is Sunday, with 7 also meaning Sunday in many systems

Special strings and shortcuts

Many implementations also accept shortcuts that replace the five fields entirely. The most common are @hourly, which runs at minute zero of every hour, @daily or @midnight, @weekly, which runs on Sunday at midnight, @monthly on the first day of the month, @yearly or @annually on 1 January, and @reboot, which runs once at startup. Not every platform supports them, so test before relying on one.

Worked examples you can adapt

Read an expression from left to right, translate each field, then say the whole schedule back in words to check it. If you can describe it in one sentence, the expression is probably right. These examples cover the patterns people use most often.

0 9 * * 1-5: 9:00 every weekday, Monday to Friday
*/15 * * * *: every 15 minutes, at 0, 15, 30 and 45 past each hour
30 2 * * 0: 2:30 every Sunday morning
0 0 1 * *: midnight on the first day of every month
0 */6 * * *: at 00:00, 06:00, 12:00 and 18:00 every day
0 18 * * 5: 6:00 pm every Friday

Common mistake: every five minutes written wrongly

A frequent slip is writing 5 * * * * when you mean every five minutes. That expression runs once an hour, at five past the hour, because the minute field holds only the value 5. The correct form is */5 * * * *. The same confusion appears with hours: 0 */4 * * * means every four hours, while 0 4 * * * means once a day at 4 am.

Watch the order of the first two fields too. 9 0 * * * runs at 00:09, nine minutes past midnight, not at 9 am. Reading the minute field first prevents this error.

Common mistake: day of month and day of week together

When both the day of month and the day of week are restricted, standard cron runs the job when either condition matches, not when both match. So 0 9 13 * 5 runs at 9 am on the 13th of each month and also every Friday. This surprises many people. If you need Friday the 13th only, use a script that checks the date, because a single expression cannot express 'both'.

Quartz and some other schedulers behave differently and require a question mark in one of the two fields, so read the documentation for your platform before assuming either behaviour.

Time zones and daylight saving

Cron usually evaluates times in the time zone of the machine or service running it, which may be UTC on a cloud server even though your team works in London. A job scheduled for 9 am may therefore run at 8 am or 10 am local time. GitHub Actions, for example, evaluates its schedules in UTC. Confirm which zone your scheduler uses and document it next to the expression.

Daylight saving creates two awkward cases. When the clocks go forward, an hour such as 01:30 on the changeover morning may not exist, and some schedulers skip the job or run it at an unexpected time. In the UK this happens on the last Sunday of March. When the clocks go back, an hour repeats, so a job can run twice. Where possible, schedule critical tasks outside the transition hours, or use UTC and convert for display.

Testing before you trust a schedule

Standard cron does not run missed jobs after a machine has been switched off, so a schedule that falls during downtime will simply be skipped. Platforms and tools such as anacron handle catch-up runs differently, which is worth checking. The cron-expression-explainer tool on this site translates an expression into plain English, so you can confirm the schedule before it reaches production.

Translate the expression into plain English and compare it with your intent
Check the next several run times against what you expect
Run the command manually first to confirm it works
Log the start and finish of each run so gaps are visible
Watch the first few runs after any change to the schedule

Strumenti citati in questa guida

Sviluppo

Cron Expression Explainer

Turn a five-field cron schedule into plain English and see its next five run times.

Sviluppo

Unix Timestamp Converter

Convert Unix timestamps to readable dates and back.

Domande frequenti

What does the asterisk mean in a cron field?

An asterisk means every possible value for that field. In the minute field it means every minute, and in the day of week field it means every day of the week. Using an asterisk in both the day of month and day of week fields means the job runs every day, since neither field restricts it. Asterisks are the most common building block, and they are often combined with a slash to create steps.

Why did my cron job not run at the scheduled time?

Several causes are common. The scheduler may be using a different time zone from the one you expect, the machine may have been switched off at the scheduled moment, or the expression may match a different time than intended. Check the service logs, confirm the zone, and test the expression with an explainer. Environment differences also matter, since cron runs jobs with a minimal set of variables and paths.

How do I run a job every 30 seconds with cron?

Standard five-field cron has no seconds field, so the shortest interval is one minute. Common workarounds include running a script that loops with a sleep command, using a scheduler that supports a seconds field, or triggering the job from a long-running process. If you need precise sub-minute timing, a dedicated task queue or a process with its own timer is usually a better fit than cron.

What is the difference between cron and crontab?

Cron is the scheduling daemon that runs in the background, while crontab is the command and file format used to store each user's schedules. You edit your own schedules with crontab -e and list them with crontab -l. The expressions you write are placed in that file. Many people use the two words interchangeably, but they refer to different parts of the system.

Does cron support time zones in the expression?

Standard cron has no time zone field, so the schedule follows the system time zone of the machine running the scheduler. Some newer platforms accept an explicit time zone setting alongside the expression, which removes much of the guesswork. Where you have the choice, pick UTC for servers and convert times for people when you display them. Always write the zone next to the schedule in your documentation.