Cron Expression Builder

A cron expression builder lets you construct cron schedule strings using a visual interface and see a plain-English description of when the schedule will trigger. It is used by developers, DevOps engineers, and system administrators who need to schedule recurring tasks, jobs, or automation pipelines without memorising cron syntax.

How to Use the Cron Expression Builder

1. Select the frequency of your job from presets (every minute, hourly, daily, weekly, monthly) or build a custom schedule.
2. Use the dropdown menus or sliders to set the minute, hour, day of month, month, and day of week values.
3. The tool generates the cron expression string in real time and displays a human-readable description.
4. Review the "next run times" preview to confirm the schedule is correct.
5. Copy the expression and paste it into your crontab, CI/CD configuration, or scheduler.

The Formula

A cron expression consists of five (or six, in extended formats) fields separated by spaces:

minute hour day-of-month month day-of-week

Each field accepts:

• A specific value: 30 (at minute 30)
• A wildcard * meaning "every"
• A range: 1-5 (values 1 through 5)
• A list: 1,3,5 (values 1, 3, and 5)
• A step: */15 (every 15 units) or 0-30/5 (every 5 units from 0 to 30)

Field ranges:

• Minute: 0 to 59
• Hour: 0 to 23
• Day of month: 1 to 31
• Month: 1 to 12 (or JAN to DEC)
• Day of week: 0 to 7 (0 and 7 both represent Sunday) or SUN to SAT

Example: 30 9 * * 1-5 means "at 09:30, Monday through Friday".

Some systems (AWS EventBridge, Jenkins, Spring) use a six-field format that adds either seconds as the first field or year as the sixth field.

Real-World Example

A data engineer needs to run a database backup job every day at 2:30 AM. They open the cron expression builder, set the minute to 30, the hour to 2, and leave the day, month, and day of week fields as wildcards.

The tool generates: 30 2 * * *

Human-readable description: "At 02:30, every day."

Next run times preview shows the upcoming trigger dates, confirming the schedule. The engineer pastes 30 2 * * * /usr/bin/backup.sh into their server's crontab.

Common Cron Expressions Reference

Some expressions used frequently in practice:

• * * * * * runs every minute
• 0 * * * * runs at the start of every hour
• 0 0 * * * runs at midnight every day
• 0 9 * * 1-5 runs at 9:00 AM on weekdays
• 0 0 1 * * runs at midnight on the first day of every month
• 0 0 1 1 * runs at midnight on 1 January each year
• */15 * * * * runs every 15 minutes
• 0 0 * * 0 runs at midnight on Sundays

Frequently Asked Questions

What is the difference between day-of-month and day-of-week? These are two independent fields. You can schedule a job on a specific date (day-of-month) or on a specific weekday (day-of-week). If both are set to non-wildcard values, most cron implementations trigger the job if either condition is met, not both. To target a specific weekday on a specific date, you may need to add logic inside your script.

Why does my cron job not run at the expected time? Common causes are: the server is in a different timezone from what you expected (cron uses the server's local timezone); a typo in the expression; the cron daemon is not running; or the script does not have execute permissions. Use a cron expression builder to verify your expression and check your server's timezone with timedatectl.

What is the difference between cron and a cron-like scheduler like GitHub Actions? Traditional cron runs on a server and executes shell commands. CI/CD platforms like GitHub Actions support cron-like schedule syntax (schedule: cron: '...') but run jobs in the cloud. AWS EventBridge, Kubernetes CronJobs, and Heroku Scheduler also use cron-inspired syntax with minor variations. Always check the specific syntax requirements of your platform.

Is */5 the same as 0,5,10,15,20,25,30,35,40,45,50,55 for minutes? Yes, they are equivalent. The step syntax */5 is simply shorthand for listing every fifth value in the field's allowed range (0 to 59 for minutes). Both expressions run the job every 5 minutes starting at minute 0.

Also try these free tools:

• Cron Generator
• Unix Timestamp
• Regex Tester

Parsing one expression field by field

A five-field expression is read left to right, and each field answers one question about the time to run. Taking 30 9 * * 1-5, the weekday morning schedule, shows the whole process.

Read the fields as a set of conditions rather than as a sequence of steps. The job runs at a moment when every field matches the current time, so 30 9 * * 1-5 means the thirtieth minute of the ninth hour, on any day, in any month, provided the weekday is Monday to Friday.

How often each common schedule runs

The number of runs a schedule produces is worth knowing before it is written into a crontab, because a job that writes a file or calls an external service scales with that number. The day counts below use a common year of 365 days.

Two rows are worth checking against intuition. 0 */6 * * * runs four times a day, not six, because the step applies inside the twenty-four hour range and starts at hour zero. */15 * * * * runs 35,040 times a year, which is a useful figure before pointing a schedule at anything with a rate limit.

What a step value expands to

A step written as */n starts at the low end of the field's own range and then takes every nth value from there. The field matters, and a step means different things in the minute field and the hour field.

The minute and hour rows are the ones that catch people out. Dividing 60 by 5 gives 12, and */5 in the minute field does produce 12 values. Dividing 24 by 5 gives 4.8, and */5 in the hour field produces 5, not 4.8. A step never produces a fraction of a run, and the count is the number of values in the range that are divisible by the step when measured from the range minimum.

The */7 row shows the same effect. Seven does not divide sixty, so the final value stops at 56 and the count is 9 rather than the 8.57 that a division would suggest. A range with an explicit end such as 0-30/5 also behaves predictably: the step runs from 0 to 30 inclusive, which gives 7 values.

Why the weekday count is not fixed

A common year holds 365 days, which is 52 whole weeks plus one day. The extra day is a weekday or a weekend day, and that decides whether a weekday schedule fires 260 or 261 times. A leap year holds 366 days, which is 52 weeks plus two days, so a weekday schedule fires 260, 261 or 262 times depending on which two days those are.

The same arithmetic applies to any day-of-week schedule. Midnight on Sunday fires 52 or 53 times a year, and a weekly job that has to run exactly 52 times a year cannot be expressed in five fields alone. Schedules with a hard annual count belong in the application logic, where the count can be checked after the fact, rather than in the cron expression, where the count depends on the calendar.

The same fields across schedulers

Five fields separated by spaces is the common form, and the family of schedulers that use it has drifted. The differences that matter are the number of fields, which field comes first, and how the two day fields interact.

Moving an expression between two of these is where most scheduling bugs come from. An expression copied from a Quartz configuration into a Linux crontab is shifted by one field, and the job fires at a time nobody intended. Check the field count and the first field before pasting anything.

How the run counts are worked out

Six rules sit behind the tables above.

• The expressions are the five-field form used by crontab on Linux and macOS. The fields are minute, hour, day of month, month and day of week, in that order, separated by single spaces.
• Every field is matched against the current time independently, and the job runs when all five match.
• When the day-of-month and day-of-week fields are both restricted, the behaviour is implementation dependent. In Vixie cron, the implementation behind most Linux systems, a job runs when either restricted field matches, not when both do.
• A step value counts from the low end of the field's own range. Minute ranges from 0 to 59, hour from 0 to 23, day of month from 1 to 31, month from 1 to 12, and day of week from 0 to 7.
• Named values such as JAN to DEC and SUN to SAT are accepted by most implementations, and case is not always significant. Numeric fields work everywhere.
• Run counts assume a common year of 365 days and no daylight saving transition. A daily schedule can fire twice or be skipped once in a year that shifts the clocks, because the daemon evaluates the expression against local time.

One practical consequence follows from the last rule. A schedule that must fire exactly once per calendar day in a timezone with daylight saving needs a guard in the job itself, because the expression describes a local clock time rather than an interval. Schedules that must run at fixed intervals are often better expressed as an interval in the scheduler that supports one.

The specification behind the format

The five-field format, the allowed ranges and the day matching rule used above are the ones documented in crontab(5) from the Linux man-pages project and in the crontab specification in the POSIX Shell and Utilities volume. Quartz publishes its own six-field and seven-field variants separately, which is why the two formats are not interchangeable even though they look alike at a glance.