Cron Expressions Explained with Practical Examples

How the five fields of a cron expression work, what the special characters mean, and ready to use schedules for common jobs.

By Utkarsh Garg · 2026-10-27 · 3 min read

The five fields

A standard cron expression has five fields separated by spaces. From left to right they are minute, hour, day of month, month and day of week. The job runs whenever the current time matches all the fields.

  • Minute: 0 to 59
  • Hour: 0 to 23
  • Day of month: 1 to 31
  • Month: 1 to 12
  • Day of week: 0 to 6, where 0 is Sunday. Many systems also accept 7 for Sunday.

Special characters

Four characters cover almost every schedule.

  • Asterisk (*) means every value in that field.
  • Comma (,) lists values, so 1,15 means the 1st and the 15th.
  • Hyphen (-) gives a range, so 1-5 in the day of week field means Monday to Friday.
  • Slash (/) gives a step, so */10 in the minute field means every 10 minutes.

Common schedules

These examples cover the jobs people schedule most often.

  • */15 * * * * runs every 15 minutes.
  • 0 * * * * runs at the start of every hour.
  • 30 2 * * * runs every day at 02:30.
  • 0 9 * * 1-5 runs at 09:00 on weekdays.
  • 0 0 1 * * runs at midnight on the first day of each month.
  • 0 0 * * 0 runs at midnight every Sunday.

Details that cause surprises

When both day of month and day of week are restricted, classic cron runs the job when either one matches, not both. So 0 0 13 * 5 runs on every 13th and also on every Friday, which is rarely what people intend.

Cron uses the time zone of the machine it runs on, which is often UTC on servers. A job set for 09:00 may fire at a different local time than you expect, and daylight saving changes can skip or repeat a run in some local time zones.

Not every scheduler uses the same syntax. Some add a seconds field in front, some add a year, and cloud schedulers often have their own rules for the day fields. Always check the documentation of the system that will run the job.

Test before you rely on it

A wrong cron expression usually fails silently: the job just runs at the wrong time or never. Translating the expression into plain English and checking the next run times is the fastest way to catch a mistake before it reaches production.