Cron Generator

A cron generator produces a valid cron expression from a plain-English description of a schedule, such as "every weekday at 8 AM" or "on the 1st of every month at midnight". It is designed for developers, system administrators, and technical users who need correct cron syntax quickly without consulting documentation or memorising field positions.

How to Use the Cron Generator

1. Describe your desired schedule in the input field or choose from common presets.
2. The tool generates the corresponding cron expression instantly.
3. Read the human-readable confirmation to verify the schedule matches your intent.
4. Check the "upcoming triggers" list to confirm the next several run times.
5. Copy the expression and use it in your crontab, pipeline configuration, or cloud scheduler.

The Formula

A cron expression follows a five-field format used by most Unix-like systems:

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

The cron generator maps plain-English input to these five fields using a set of parsing rules:

• "Every X minutes" sets the minute field to */X and all other fields to *.
• "At H:MM AM/PM" converts the time to 24-hour format and sets minute and hour explicitly.
• "Every weekday" sets day-of-week to 1-5 (Monday to Friday).
• "On the Nth of every month" sets day-of-month to N and all other non-time fields to *.
• "Every X hours" sets the hour field to */X.

The generator validates the output to ensure all values fall within their allowed ranges and the expression is syntactically correct. It also detects impossible combinations, such as scheduling a job on 31 February.

Real-World Example

A developer needs to schedule a script that checks for overdue invoices every morning at 7:30 AM, Monday through Friday.

They enter: "Every weekday at 7:30 AM."

The cron generator produces: 30 7 * * 1-5

Confirmation: "At 07:30, Monday through Friday."

Upcoming triggers: Monday 30 June 07:30, Tuesday 1 July 07:30, Wednesday 2 July 07:30...

The developer pastes 30 7 * * 1-5 /home/billing/check-invoices.sh into their server's crontab file.

Cron Generator vs Cron Expression Builder

These two tools serve the same purpose from opposite directions. A cron generator takes a human description and produces a cron expression. A cron expression builder starts with the expression fields and lets you set them visually, producing both the expression and a human description. In practice, both tools typically offer both input modes. Use whichever direction of conversion is more convenient for your current task.

Frequently Asked Questions

Can I generate cron expressions for AWS EventBridge or Kubernetes? Standard cron generators produce five-field Unix cron expressions. AWS EventBridge uses a six-field format with a year field, and its own syntax for certain features. Kubernetes CronJob uses standard five-field cron syntax. Always verify your expression against the documentation for your specific platform before deploying to production.

What happens if I schedule a cron job for a time that does not exist, such as during a daylight saving time clock change? Behaviour depends on the system's cron daemon and timezone configuration. Some daemons skip the missing hour; others run the job when the clock catches up. To avoid issues, schedule jobs at times that never fall in the ambiguous DST transition window, such as 2:30 AM to 3:00 AM in regions that observe DST.

How do I run a job every 30 seconds? Standard cron has a one-minute minimum interval. To run a job every 30 seconds, the common workaround is to schedule two cron entries: one that runs on the minute and one that runs with a 30-second delay using a sleep 30 && prefix in the command. Alternatively, use a job scheduler that supports sub-minute intervals, such as systemd timers.

Can I test a cron expression without waiting for it to trigger? Yes. Tools like crontab -l list your current jobs and cron daemon logs (usually in /var/log/syslog or /var/log/cron) show recent runs. You can also temporarily change the expression to run every minute, confirm it works, then update it to the correct schedule.

The five fields and the values each one accepts

A Unix cron expression carries five time fields. The crontab(5) manual page documents the format that cron implementations on Linux and macOS follow:

Month and day names are case insensitive, and both fields accept lists and ranges, so mon,wed,fri and jan-mar are valid. An asterisk stands for the whole range of a field. The validation step in the generator checks values against these bounds, which matters because a cron daemon does not always report a bad value when it reads the file. It can simply never run the job.

The characters that build a schedule

Six symbols do all the work inside a field.

The named schedules save typing and remove a class of mistakes. The crontab(5) definitions are:

A step divides the range it sits in, so the runs per day for a few common minute fields work out as follows. A day holds 1,440 minutes.

Three schedules checked against a real calendar

The upcoming triggers list on the tool is the fastest way to catch a mistake, because a calendar month does not contain a whole number of weeks. Working the numbers by hand for 2026 shows where the surprises sit.

The expression 30 7 * * 1-5 runs at 07:30 on weekdays. A 365 day year holds 52 full weeks and one extra day. The 52 weeks contribute 260 weekday slots, and the extra day is 1 January 2026, which falls on a Thursday, so it contributes one more weekday. That gives 261 runs in 2026. The same count applies to 2025, where 1 January also landed on a weekday.

The expression 0 0 1,15 * 5 looks like a monthly and weekly schedule combined. It behaves as one schedule plus another, then subtracts the overlap. Testing it against the 2026 calendar gives 74 runs, and the arithmetic behind that number is the useful part:

The first six triggers for that expression are 1 January, 2 January, 9 January, 15 January, 16 January and 23 January. Notice the pair of dates in the first half of January. The schedule does not mean "the first Friday and the fifteenth Friday of each month".

An expression can also be syntactically valid and impossible. 0 0 31 2 * asks for midnight on 31 February, a date the calendar never produces. Run against 2026 it fires zero times. The generator flags this class of combination when it can see it, since the alternative is a crontab line that looks correct and never executes.

The day-of-month and day-of-week rule that surprises people

When both day fields are restricted, cron joins them with OR rather than AND. The crontab(5) manual page states it directly: if both fields are restricted, the command runs when either field matches.

That rule explains two counts that look wrong until you apply it. For 0 0 1 * 5, the schedule fires 63 times in 2026: 52 Fridays, 12 firsts of the month, and one day that was both, counted once. Without the OR rule the expression would fire on the roughly four or five dates a year that are both a Friday and the 1st, and 63 would be nearer 4.

To get an AND relationship, restrict one field and leave the other open, then move the second condition into the command itself. A script that checks the date before acting is a reliable way to build "the first Friday of the month" from the five fields cron gives you.

Assumptions the generator makes

The output is a standard five-field Unix cron expression, and four assumptions come with that:

1. The minimum interval is one minute. Cron examines entries once a minute, so a request for fewer than 60 seconds cannot be expressed in the five fields. Two entries, or a systemd timer with a sub-minute interval, are the usual ways round it.
2. The expression carries no timezone. The daemon applies the timezone of the machine or container it runs on, so the same line means different wall-clock times in different environments. Set the timezone on the host or in the job wrapper rather than assuming the expression travels.
3. Daylight saving shifts the wall-clock meaning of an hour. The crontab(5) notes cover both directions: a time that does not exist during the spring shift never matches and the job does not run, and a time that occurs twice during the autumn shift causes matching jobs to run twice. Schedules that must not drift belong outside the 02:00 to 03:00 window in a region that observes the shift.
4. Five fields is the Unix convention, not a universal one. AWS EventBridge adds a sixth field for the year, and Quartz uses a seven field expression with seconds at the front. Kubernetes CronJob takes the standard five. The generator produces the Unix form, so confirm the target platform before pasting.

The format itself is old and stable. POSIX specifies a crontab entry as six fields separated by blanks, with the first five carrying the minute, hour, day of month, month and day of week, and the sixth holding the command. The @ nicknames, name ranges and steps are extensions that the major implementations added on top.

Also try these free tools:

• Cron Expression Builder
• Unix Timestamp
• Regex Tester