An expression you cannot check is a guess
Concatenating five fields is the easy half. The half that catches people is that a syntactically perfect crontab line can fire at three in the morning when you meant three in the afternoon, or seven times on the first of the month and never again, and nothing about the line itself tells you so.
Every expression this page builds is expanded against a real calendar before it is shown to you. The stepper walks months, then days, then hours, then minutes, skipping whole months and whole days that cannot match rather than approximating with a fixed interval. That matters for schedules like 0 0 29 2 *, which fires roughly once every four years — an approximation that adds a fixed number of seconds to find the next occurrence would either miss it or take a very long time to reach it.
The two day fields are joined with OR
Fields three and five both select days, and when both are restricted the standard crontab combines them with OR rather than AND. 0 12 1 * 1 does not mean "the first of the month, if it is a Monday". It means "the first of the month, and also every Monday", which is roughly five times as many runs as the AND reading.
Implementations disagree here, and that is the dangerous part. Vixie cron and the crontab on most Linux systems use OR. Quartz refuses to accept an expression with both fields restricted and requires a question mark in one of them. Several scheduling libraries quietly use AND. Because all four behaviours accept the same text, the expression cannot tell you which one you are getting.
The output flags this whenever it applies. The safe move is to restrict one day field and leave the other as an asterisk; if you genuinely need "the first Monday of the month", that is not expressible in five-field cron at all and belongs in the job itself or in a scheduler with an explicit Nth-weekday rule, such as the one behind the recurring date calculator.
Cron reads the wall clock, and the wall clock lies twice a year
Cron matching is a comparison against local wall clock fields. It has no concept of elapsed time, which means daylight saving transitions do something to your schedule that the expression cannot express.
On the spring-forward morning the local clock never reads 02:30, so a job scheduled at 02:30 has no matching minute and, on most daemons, simply does not run that day. On the fall-back morning the hour from 01:00 repeats, so a job scheduled at 01:30 has two matching minutes. Some daemons run it twice, some suppress the second, some run jobs missed during a jump shortly afterwards. The behaviour is a property of the daemon, not of the expression.
The listed run times here are wall clock times, so they show what the expression matches. Whether the machine honours all of them on those two mornings is a separate question, and the only schedule immune to it is one that avoids the 01:00 to 03:00 local window entirely, or a machine whose clock is set to UTC. If you need to know which mornings are affected in a given zone, look them up on the daylight saving change dates page and check your schedule against them.
Choosing between the presets and the raw fields
The preset shapes cover the schedules most jobs actually want and produce a conventional expression rather than an unusual one. Every N minutes writes a step value in the minute field; a weekday schedule writes a comma list; a monthly schedule writes a plain day number.
Switch to the five-field mode when you need something the presets do not cover: several times a day at irregular hours, a range with a step such as 0 9-17/2 * * *, or a restriction to certain months. Steps, ranges, comma lists and three-letter month and weekday names are all accepted, and each field is reported back with the exact set of values it matched so you can confirm the parse rather than trusting it.
One asymmetry is worth remembering when you pick a monthly day: cron does not clamp. Ask for the 31st and February, April, June, September and November are skipped entirely rather than falling back to the last day. If you wanted the end of the month, the usual workaround is to schedule the job daily and let it check the date itself. The interval column in the run table makes a schedule like that visible at a glance, because the gaps stop being equal.
Questions people ask
Why does my expression with both day fields set fire so often?
Because the standard crontab combines the day-of-month and day-of-week fields with OR. Setting field three to 1 and field five to 1 gives you the first of the month plus every Monday, not the first Monday. Restrict one and leave the other as an asterisk. Note also that implementations differ — Quartz rejects the combination outright and some libraries use AND — so the same text can behave differently in different schedulers.
Are the listed run times adjusted for daylight saving?
No, and that is deliberate. Cron matches wall clock fields, so the listed times are the wall clock times the expression matches. What a particular daemon does on the two transition mornings — skipping a run, running it twice, or catching up afterwards — is a property of that daemon. Keeping sensitive jobs outside 01:00 to 03:00 local time sidesteps the whole question.
How do I schedule something for the last day of every month?
Five-field cron cannot express it. Day 31 is not clamped to the end of shorter months; those months are skipped instead. The conventional workaround is to run the job every day and have the job itself check whether tomorrow is the first, or to use a scheduler with an explicit last-day rule.
Does it support seconds, or the @daily shorthands?
Not in this builder. It produces the classic five-field form, which is what a system crontab expects. Six-field expressions with a leading seconds column and the @-prefixed shorthands are read by the cron expression parser instead, which is the right tool for interpreting an expression somebody else wrote.
Is the expression sent anywhere?
No. Parsing, calendar stepping and formatting all happen in your browser. Nothing about your schedule leaves the machine.