Cron Expression Generator_
Type an expression and read what it means in English, field by field, with the next five times it will actually fire. Pick a preset instead if you would rather start from the schedule and work back to the syntax — both directions are the same tool.
The dialect selector is the part that matters more than it looks. Standard crontab, Quartz and Jenkins share a syntax that is almost the same and disagree in ways that fail silently: Quartz puts seconds in front, numbers weekdays from a different starting point, and demands a question mark where crontab wants a star.
Every 15 minutes.
- Input
- A cron expression in the dialect you select — five fields for crontab and Jenkins, six or seven for Quartz. Names work too: MON, FRI, JAN, DEC.
- Output
- The schedule in English, every field expanded to the values it covers, and the next five occurrences computed in your browser's local time zone.
- Processing
- Parsed and walked forward in this tab. The run times come from your own clock, which is also the honest answer to when a job fires — the server's clock is the one that counts, and it may not be this one.
- Limits
- Jenkins H cannot be resolved here: the value is hashed from the job name, so only Jenkins knows the minute. Quartz L, W and # are not evaluated either, and the page says so rather than guessing.
- The rule that surprises everyone
- When day-of-month and day-of-week are BOTH restricted, standard cron runs when EITHER matches, not both. "0 0 1 * MON" fires on the first of the month and on every Monday — roughly five times as often as the author intended. The page warns when an expression is in that shape, and the next-run list shows it happening.
Five fields, and the traps between them
What each position controls
Minute, hour, day of month, month, day of week — in that order, separated by spaces. Each field takes a star for "every", a number, a range like 9-17, a list like 0,30, or a step written with a slash. A job runs when every field matches the current time, which is why 0 3 * * * is daily at three in the morning: the minute and hour are pinned and the three date fields accept anything.
The two day fields are an OR, not an AND
This is the one genuine surprise in the syntax. Every other field narrows the schedule; the day pair widens it. If you restrict day-of-month and day-of-week, the job runs whenever either one matches — so 0 0 1 * MON is not "the first of the month, if it is a Monday" but "the first of the month, and also every Monday". The behaviour is in POSIX and it is not a bug, but almost nobody writes it deliberately. Leave one of the two as a star unless you truly want the union.
Quartz is not crontab, and the difference is silent
Java schedulers — Quartz, and Spring's @Scheduled behind it — use six fields with seconds first. Paste a crontab line into one and every value shifts a position: your minutes become seconds and your hours become minutes. Weekday numbering differs too, running 1 to 7 with Sunday as 1, so crontab's 1 for Monday means Sunday in Quartz. And Quartz requires a ? in exactly one of the two day fields, which is its way of forcing you to resolve the OR problem above.
Jenkins adds a letter that has no fixed value
H means "pick something for me". Jenkins hashes the job name into the field's range, so H 3 * * * runs once between 03:00 and 03:59 at a minute that is stable for that job and different from its neighbours. It exists because a thousand jobs written as 0 3 * * * all start in the same second and flatten the machine. No calculator can tell you which minute you will get, and one that pretends to is guessing.
Time zones, and the two nights a year that go wrong
Cron uses the clock of the machine it runs on, not yours and not UTC unless the machine is set that way. Daylight saving does the rest: on the night clocks go forward, a job scheduled at 02:30 has no 02:30 to run at and is skipped, and on the night they go back it can run twice. Anything that moves money or sends messages wants a server on UTC, and anything that must run exactly once wants a lock rather than a schedule that assumes it.
Type it, read it, or start from a preset
- 01Type or paste the expression. It parses on every keystroke, and an invalid one says which field is wrong rather than just refusing.
- 02Read the sentence at the top and the next five run times underneath — those are computed, not looked up from a table of common patterns.
- 03Switch dialect if the expression is for Quartz or Jenkins. Field counts, weekday numbering and the question-mark rule all change with it.
- 04Or press a preset and work backwards: pick the schedule you want, then read the syntax it produced.
An expression from a config you did not write
Somebody left a schedule in a deployment file and nobody remembers what it does. Reading it aloud is faster than reasoning about five fields.
30 2 * * 1-5
At 02:30 on MON, TUE, WED, THU and FRI. Next: Wed 02:30, Thu 02:30, Fri 02:30…
A crontab line pasted into a Spring scheduler
The job either never fires or fires constantly. Quartz reads six fields with seconds in front, so every value has shifted one place left.
0 12 * * *
0 0 12 * * ? (seconds, then minute 0, hour 12, and ? for the unused day field)
A monthly report that also runs every Monday
The intent was the first of the month, only on weekdays. Restricting both day fields turns the schedule into a union rather than an intersection.
0 6 1 * 1-5
Fires on the 1st AND every weekday. Use 0 6 1 * * and check the weekday in the job.
A thousand Jenkins jobs starting together
Every job was written to run at 03:00, so every agent wakes at once and the queue collapses. H spreads them deterministically.
0 3 * * *
H 3 * * * → a stable minute between 03:00 and 03:59, per job
Schedules people actually ask for
| Expression | What it does |
|---|---|
| * * * * * | Every minute |
| */5 * * * * | Every 5 minutes |
| */15 * * * * | Every 15 minutes |
| 0 * * * * | Every hour, on the hour |
| 0 3 * * * | Every day at 03:00 |
| 0 9 * * 1-5 | Weekdays at 09:00 |
| 0 0 * * 0 | Every Sunday at midnight |
| 0 0 1 * * | First of the month |
These eight are what the search data asks for rather than a tour of the syntax: every-five-minutes alone outweighs most of the rest put together. A preset that quietly never fired would be worse than no preset, so each one has to yield a real occurrence before it ships.
Habits that keep a schedule honest
- Leave one of the two day fields as a star. If you need "the first, but only on a weekday", schedule the wider one and check the day inside the job.
- Put the server on UTC for anything that must not run twice. Daylight saving skips one hour a year and repeats another, and cron obeys the local clock without comment.
- Avoid the top of the hour when several jobs share a machine. A minute chosen at random spreads the load, and on Jenkins
Hdoes it for you. - Redirect output somewhere. A cron job that prints to stdout mails it to the local user by default, which usually means it vanishes — append
>> /var/log/yourjob.log 2>&1. - Remember that cron gives you almost no environment. No PATH to speak of, no shell profile, no working directory you chose — use absolute paths for both the interpreter and the script.
Where a correct expression still misbehaves
The two day fields widen rather than narrow
Restricting both day-of-month and day-of-week makes cron run on either. It is the single most common misreading of the syntax, and it makes a monthly job run weekly.
A six-field expression in a five-field scheduler
Crontab reads the first field as minutes. Hand it a Quartz expression and the seconds field becomes your minutes, the minutes become hours, and the schedule is wrong in a way that still looks plausible.
Overlapping runs
Cron starts a new run on schedule whether or not the last one finished. A five-minute job on a five-minute schedule eventually runs several copies at once — use a lock file or flock if the job cannot tolerate that.
The environment is not your shell
Cron runs with a minimal environment and a different PATH. A script that works when you run it and fails from cron is almost always missing an absolute path or an exported variable, not scheduled wrongly.
Dialects, fields, and how the runs are computed
- Standard
- Five fields: minute, hour, day of month, month, day of week. Weekdays 0 to 7 with both 0 and 7 meaning Sunday. Names accepted for months and days.
- Quartz
- Six fields with seconds first, plus an optional seventh year. Weekdays 1 to 7 with Sunday as 1. A question mark is required in exactly one of the two day fields.
- Jenkins
- Five fields plus H, which hashes the job name into the field range. Expressions containing H are accepted and described, but no run times are shown, because the value belongs to Jenkins.
- Run times
- Computed by walking the clock forward one minute at a time and testing every field, with a four-year ceiling. Slower than field arithmetic and obviously correct, including the either-day rule and 29 February.
- Not evaluated
- Quartz L, W and # modifiers, and the @reboot shortcut, which depends on a machine starting rather than on a time.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about cron expressions and crontab syntax
What does */5 * * * * mean?
Every five minutes, all day, every day. The slash is a step: applied to the minute field with a star it means "every fifth value from 0", giving 0, 5, 10 and so on. It is the most searched schedule there is, along with every 15 minutes and hourly.
How do I write a cron job that runs every hour?
0 * * * * runs at the top of every hour. Do not use * * * * * expecting hourly — that is every minute, 1,440 times a day. If several jobs share a machine, pick a minute other than 0 so they do not all start together.
Why does my monthly cron job also run every week?
Because you restricted both day fields. When day-of-month and day-of-week are both set to something other than a star, cron runs when either matches, not both. Set one of them back to a star and check the other condition inside the job.
What is the difference between crontab and Quartz cron expressions?
Quartz uses six fields with seconds first, so every crontab field shifts one position. It also numbers weekdays 1 to 7 with Sunday as 1, where crontab uses 0 to 7 with both 0 and 7 as Sunday, and it requires a question mark in exactly one day field. A crontab line pasted into a Spring scheduler is usually accepted and usually wrong.
What does H mean in a Jenkins cron expression?
It tells Jenkins to choose a value in that field, hashed from the job name so the choice is stable for the job and spread across jobs. H 3 * * * runs once somewhere between 03:00 and 03:59. No external tool can tell you the exact minute, because it depends on the job name inside Jenkins.
Does cron use UTC or local time?
The local time of the machine it runs on. That makes daylight saving a real hazard: a job scheduled inside the hour that is skipped in spring does not run at all, and one inside the hour repeated in autumn can run twice. Set the server to UTC for anything where that matters.
How do I run a cron job on weekdays only?
0 9 * * 1-5 runs at 09:00 Monday to Friday. You can write the names instead — 0 9 * * MON-FRI — which most implementations accept and which is considerably easier to read six months later.
Why does my cron job work manually but not from cron?
Almost always the environment rather than the schedule. Cron runs with a minimal PATH, no shell profile and a working directory you did not choose. Use absolute paths for the interpreter and the script, export anything the script relies on, and redirect output to a log so the failure is visible.
Are my expressions sent anywhere?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.