Cron Expression Builder & Explainer
Type a cron schedule or use the visual builder to get an instant plain-English translation and the next five run times. Perfect for server jobs, CI pipelines, and scheduled tasks. Nothing uploaded.
Cron Expression
Meaning
Presets
Visual Builder
Next 5 Run Times
30-Day Run Density
Darker = more runs that day. Hover for count.
Export
Copies the expression wrapped in the correct GitHub Actions YAML schedule syntax.
Learn more: reading a cron expression like a scheduler does
The five fields and what each one accepts
A standard cron expression is five space-separated fields in a fixed order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7). Both 0 and 7 mean Sunday, and this tool folds 7 down to 0 before it matches anything.
An asterisk in a field means every value it can hold. Otherwise a field takes a single number, a comma list like 1,15, a range like 1-5, or a step like */15 or 9-17/2.
A value outside that field's own range is rejected by name, so typing 25 in the hour field reports "Invalid hour: 25 out of range 0-23" instead of quietly scheduling something you did not mean.
The five-field layout dates to Version 7 Unix in 1979, when Brian Kernighan rewrote cron as a background daemon and, as CompuTools' history of cron puts it, established "the syntax we recognize today".
The sixth field is not always seconds
Quartz, the Java scheduler, puts a seconds field in front of the usual five. That is where the idea of six-field cron comes from, and it is the convention the 6-field toggle on this page follows.
Other schedulers count to six differently. Amazon EventBridge also requires six fields, but its extra field is a year (1970-2199) at the end, and it refuses any rate faster than once a minute. GitHub Actions has no sixth field at all: it is plain POSIX cron, UTC by default, and "the shortest interval you can run scheduled workflows is once every 5 minutes".
This is why a Quartz expression pasted into a Unix crontab fails quietly. With no seconds slot to absorb it, every value slides one position left, so the hour you wanted becomes a minute and the day you wanted becomes an hour. Count the fields before you move a schedule between systems.
Day of month and day of week together
When both day fields are restricted, standard cron treats them as OR rather than AND. The crontab(5) man page puts it plainly: "the command will be run when either field matches the current time". Under that rule "30 2 15 * 5" fires on the 15th of every month and also on every Friday.
The run preview on this page uses AND, so for that expression it only lists the 15ths that happen to fall on a Friday. If your expression pins both day fields, read the preview as the narrower answer and check your own scheduler's documentation.
The preview also works from your browser's clock, not the server's. Cron runs the job in whatever timezone the daemon is configured for, and that mismatch is usually what went wrong when a job fires at a surprising hour.
FAQ
What does */15 actually mean?
A step counts from the bottom of that field's range, not from the moment you save the job. In the minute field */15 gives :00, :15, :30 and :45 of every hour. In the day-of-month field */7 starts at day 1 and restarts every month, so it fires on the 1st, 8th, 15th, 22nd and 29th, then jumps back to the 1st after a gap shorter than a week.
Why does the run list sometimes come back short or empty?
The search scans one minute at a time and stops after a year. An expression that can never match, like the 30th of February, comes back empty, and a once-a-year expression fills only the first of the five slots. Treat a short list as a prompt to re-read the expression.
Can I schedule something every 30 seconds?
Only on a scheduler that reads a seconds field, such as Quartz, and you can turn on the 6-field toggle here to build that expression. Standard Linux crontab works in whole minutes, GitHub Actions will not go below five minutes, and EventBridge rejects anything faster than once a minute.