Skip to content
Reembun
Cron generator icon
Developer

Cron expression generator

Build or decode a cron expression, read it back in plain English, and see the next eight times it will actually fire.

Five fields: minute, hour, day of month, month, day of week.

0

minute

0-59

9

hour

0-23

*

day of month

1-31

*

month

1-12

1-5

day of week

0-6

Common schedules


In plain English

At 09:00 on Monday, Tuesday, Wednesday, Thursday and Friday.

Next runs, in your local time

1Fri, Sep 11, 202609:00 AM
2Mon, Sep 14, 202609:00 AM
3Tue, Sep 15, 202609:00 AM
4Wed, Sep 16, 202609:00 AM
5Thu, Sep 17, 202609:00 AM
6Fri, Sep 18, 202609:00 AM
7Mon, Sep 21, 202609:00 AM
8Tue, Sep 22, 202609:00 AM
Minutes matched
1
Hours matched
1
Months matched
12

Runs are shown in your browser’s local time zone. A server runs cron in its own zone, usually UTC, which is the single most common reason a job fires at an unexpected hour. Check with timedatectl or set CRON_TZ explicitly.

Ready. Runs locally on your device.

Your files stay on your device. The tool works directly in your browser, using your device to process your files. Nothing is sent to our servers, and we never receive, store, or see your files or figures.

Share

Share this page

Share result

Your results

Use the tool above first. Whatever it works out shows up here, ready to copy or share.

Cite

Cite this page

Reembun. (2026, July 28). Cron expression generator. https://reembun.com/cron-generator
Pick a style, then copy the reference. The access date is today.

How to use it

  1. Build the schedule

    Use the pickers for minute, hour, day of month, month and day of week, or type the five fields straight into the expression box.

  2. Read it back in plain English

    The sentence under the expression says what it will actually do. Most cron mistakes are visible right here.

  3. Check the next runs

    The next four run times are listed, which is the fastest way to catch a schedule that fires far more often than you meant.

  4. Copy the expression

    Copy expression gives the line to paste into a crontab, a CI schedule or a scheduler UI.

The five fields

┌───────────── minute (0-59)
│ ┌─────────── hour (0-23)
│ │ ┌───────── day of month (1-31)
│ │ │ ┌─────── month (1-12)
│ │ │ │ ┌───── day of week (0-6, Sunday = 0)
│ │ │ │ │
* * * * *
CharacterMeaningExample
*Every value* * * * * means every minute
,A list0 9,17 * * * means 9am and 5pm
-A range0 9 * * 1-5 means weekdays
/A step*/15 * * * * means every 15 minutes

Common schedules

ExpressionMeaning
*/5 * * * *Every 5 minutes
0 * * * *Hourly, on the hour
0 0 * * *Daily at midnight
0 9 * * 1-5Weekdays at 9am
0 0 1 * *First of the month
0 0 * * 0Every Sunday
0 0 1 1 *Once a year

The day-field trap

This is the single most consequential thing to understand about cron, and it surprises almost everyone.

When both day-of-month and day-of-week are restricted, the expression fires when either matches. Not both.

0 0 1 * 1

Reads naturally as “midnight on the first of the month, if it is a Monday”. It actually means “midnight on the first of the month, and also midnight every Monday”, roughly five times a month rather than once or twice a year.

When only one of the two fields is restricted, only that one applies. The OR behaviour appears only when both are set, which is why it goes unnoticed until a job runs far more often than intended.

Time zones

Cron runs in the system time zone, which on most servers and in most containers is UTC.

timedatectl                    # check the system zone
CRON_TZ=Asia/Jakarta           # set at the top of a crontab

Daylight saving adds two failure modes on systems whose zone observes it:

  • A job scheduled in the hour that is skipped in spring may not run at all
  • A job scheduled in the hour that repeats in autumn may run twice

The usual mitigation is to schedule anything critical outside the 01:00-03:00 window, or to run the system in UTC and handle local time in the application.

Macros

Most implementations accept these shorthands:

MacroEquivalent
@yearly0 0 1 1 *
@monthly0 0 1 * *
@weekly0 0 * * 0
@daily0 0 * * *
@hourly0 * * * *
@rebootAt startup

Dialects that differ

Six-field cron adds a leading seconds field. Used by Spring, Quartz and some schedulers. A five-field expression pasted into a six-field parser shifts every field by one position, so a daily job becomes an hourly one.

Quartz adds ? for “no specific value”, L for last, W for nearest weekday and # for nth-of-month. These are not standard cron and will error on a Unix crontab.

AWS EventBridge uses six fields and requires ? in one of the two day fields, a rule that exists precisely to sidestep the OR ambiguity described above.

This tool handles standard five-field cron only, and says so rather than guessing.

Common questions

What do the five fields mean?

In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-6, where 0 is Sunday). Many implementations also accept 7 for Sunday and three-letter names like MON and JAN.

Why does my job run more often than expected?

Almost always the day-field OR rule. When both day-of-month and day-of-week are restricted, POSIX cron fires when EITHER matches, not both. So 0 0 1 * 1 runs on the 1st of every month AND on every Monday, which is rarely what anyone means.

Why does my job run at the wrong hour?

Because the server runs cron in its own time zone, usually UTC, not yours. Check with timedatectl, or set CRON_TZ at the top of the crontab. Daylight saving adds a second trap: jobs scheduled in the skipped hour may not run at all, and jobs in the repeated hour may run twice.

Does this support seconds or Quartz syntax?

No, deliberately. Six-field expressions with seconds and the Quartz dialect with ? L W and # differ enough that quietly accepting them would produce confidently wrong run times. They are rejected with a message instead.

Last reviewed