Cron expression generator
with a live next-run preview.
Answer two questions — when, and how often. The builder writes the five-field cron expression, reads it back in plain English, and lists the next ten runs before it touches a crontab.
A cron expression is five fields.
Every cron expression answers the same five questions, left to right — here on a real schedule.
Read as a sentence: Monday to Friday, at 03:30. 30 3 * * 1-5
See the schedule before cron runs it
A cron expression is write-once, debug-in-production by default — the first real test is the 3 a.m. run. This generator moves that test into your browser:
- Structured questions, not guesses. Frequency, day, time — every ambiguity in the English version becomes an explicit control.
- The next ten runs, computed. A real parser walks the calendar so you can read the schedule as dates, not syntax.
- Portable POSIX output. Five fields, numbers only — runs on any crontab, Alpine to AIX. The exotic symbols stay flagged, not generated.
Read a cron expression like a native
*/15 9-17 * * 1-5Six symbols do all the work.
Five are portable. The sixth breaks the moment you paste it into a crontab.
Match everything — the default, and the loudest. In the minute field it means sixty runs an hour, which is where the “why did this run 60 times” ticket starts.
A step — every 5th value. Steps don’t carry across fields: */90 in the minute field silently becomes “at :00” — a 90-minute cadence needs two lines.
A range — Mon–Fri in the weekday field, 9–17 in the hour field. Combine with a list: 1-5,0 is weekdays plus Sunday.
A list — exact values, comma-separated. The portable way to say “twice an hour” or “January, April, July, October”.
Nicknames — @hourly @daily @weekly @reboot. Handy where supported, but @reboot fires when the cron daemon starts, which isn’t always a boot.
Not cron. # L W ? belong to Quartz — Jenkins, Spring, some CI tools. Paste them into a crontab and it won’t install the line.
Nine cron expressions you’ll actually use.
Every one is valid POSIX. For the long tail, like “every March 2nd at 5:30 PM”, see our cron examples library.
Where a correct cron still bites.
Both computed live, in your browser — no server round-trip.
Common cron expression questions
It turns a schedule you can say, like “every weekday at nine”, into the five-field expression cron actually reads: 0 9 * * 1-5. This one goes further. It reads the expression back in English and computes its next ten run times, so you check the schedule as dates. It also flags the two classic traps: the day-field OR rule, and the star-for-zero mistake.
Left to right: minute (0–59), hour (0–23), day of month (1–31), month (1–12), day of week (0–7, where both 0 and 7 mean Sunday). Each field takes a number, a list (0,30), a range (1-5), a step (*/15), or * for “any”. Some schedulers add a sixth field for seconds (Quartz, Spring) — a crontab won’t accept it.
Not in one line — steps don’t carry remainders across fields, so */90 in the minute field just means “at :00”. The answer is two crontab lines that interleave: 0 0-21/3 * * * (00:00, 03:00, 06:00…) plus 30 1-22/3 * * * (01:30, 04:30, 07:30…) — together, every 90 minutes. The same trick covers any cadence that doesn’t divide 60.
Because the minute field was *. * 3 * * * means “every minute where the hour is 3” — 03:00 through 03:59, sixty runs. What you meant was 0 3 * * *. It’s the classic cron mistake, and the reason this tool always writes an explicit minute unless you literally choose “every minute”.
Cron fires when either matches — union, not intersection. It’s in the POSIX spec, and it catches people out. Take 0 9 1-7 * 1, a natural attempt at “the first Monday of the month”. It runs on days 1–7 and every Monday: 10 or 11 mornings a month instead of one. The trap view on this page computes both readings side by side, and shows the portable fix.
The server’s local time — cron has no time-zone field. If the box runs UTC (most cloud images do), 09:00 in the crontab is 09:00 UTC. Some crons (cronie on RHEL/Fedora, FreeBSD) honor a CRON_TZ= line; classic Debian vixie-cron doesn’t. And mind DST if the server runs a local zone: on changeover nights 02:30 can happen twice — or never. Scheduling outside 01:00–03:00, or keeping servers on UTC, sidesteps it entirely.
Cron logs that it started the job; nothing built-in tells you it succeeded. Three layers: redirect output to a log (>> /var/log/job.log 2>&1), set MAILTO= to an address someone reads, then put an independent check on the result. The third layer works wherever the output is visible from outside: a regenerated page, a renewed certificate, a sitemap. The “3 a.m. problem” view on this page walks the whole failure mode.
Keep exploring
Nemokami įrankiai – tik pradžia.
Uptimia rūpinasi jūsų svetainių sveikata.
Veikimo laikas, SSL, domeno galiojimo pabaiga, puslapių greitis, transakcijos – stebima iš 171+ vietos visame pasaulyje. Nemokama 30 dienų.