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
| 1 | Fri, Sep 11, 2026 | 09:00 AM |
| 2 | Mon, Sep 14, 2026 | 09:00 AM |
| 3 | Tue, Sep 15, 2026 | 09:00 AM |
| 4 | Wed, Sep 16, 2026 | 09:00 AM |
| 5 | Thu, Sep 17, 2026 | 09:00 AM |
| 6 | Fri, Sep 18, 2026 | 09:00 AM |
| 7 | Mon, Sep 21, 2026 | 09:00 AM |
| 8 | Tue, Sep 22, 2026 | 09: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 result
Cite
Cite this page
Reembun. (2026, July 28). Cron expression generator. https://reembun.com/cron-generator
How to use it
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.
Read it back in plain English
The sentence under the expression says what it will actually do. Most cron mistakes are visible right here.
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.
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)
│ │ │ │ │
* * * * *
| Character | Meaning | Example |
|---|---|---|
* | Every value | * * * * * means every minute |
, | A list | 0 9,17 * * * means 9am and 5pm |
- | A range | 0 9 * * 1-5 means weekdays |
/ | A step | */15 * * * * means every 15 minutes |
Common schedules
| Expression | Meaning |
|---|---|
*/5 * * * * | Every 5 minutes |
0 * * * * | Hourly, on the hour |
0 0 * * * | Daily at midnight |
0 9 * * 1-5 | Weekdays at 9am |
0 0 1 * * | First of the month |
0 0 * * 0 | Every 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:
| Macro | Equivalent |
|---|---|
@yearly | 0 0 1 1 * |
@monthly | 0 0 1 * * |
@weekly | 0 0 * * 0 |
@daily | 0 0 * * * |
@hourly | 0 * * * * |
@reboot | At 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
