The Cron to English Converter translates a five-field cron expression into a plain-English schedule, so you can confirm that a backup, report, or cleanup job runs when you think it does before you deploy it. Paste an expression such as 30 14 1 * * and the tool describes each field and assembles a readable sentence.
How It Works
A standard cron expression has five fields in fixed order: minute, hour, day of month, month, and day of week. The converter validates that exactly five fields are present and that each uses only digits and the operators asterisk, slash, comma, and hyphen. It then describes each field: an asterisk becomes "every", a slash becomes a step such as "every 15 minutes", a hyphen becomes a range such as "1 through 5", and single numbers in the month and weekday fields become names such as January or Monday.
The five fields
| Position | Field | Range | Example meaning | |---|---|---|---| | 1 | Minute | 0-59 | 30 means at minute 30 | | 2 | Hour | 0-23 | 14 means 2 PM | | 3 | Day of month | 1-31 | 1 means the 1st of the month | | 4 | Month | 1-12 | Names shown, such as March | | 5 | Day of week | 0-7 | 0 and 7 are Sunday; names shown |
Operators
| Symbol | Meaning | Example | |---|---|---| | * | Every allowed value | * in hour means every hour | | / | Step interval | */15 in minute means every 15 minutes | | - | Inclusive range | 1-5 in weekday means Monday to Friday | | , | List of values | 1,15 in day means the 1st and 15th |
Worked examples
30 14 1 * * converts to "At minute 30 hour 14, on day 1 of every month, every weekday." In ordinary terms: 2:30 PM on the first day of every month.
*/15 * * * * converts to "At every 15 minutes every hour, on every day of every month, every weekday." That is a job running at minutes 0, 15, 30, and 45 of every hour.
0 9 * * 1-5 is the classic weekday job: 9:00 AM Monday through Friday. Note that in the day-of-week field, both 0 and 7 mean Sunday in standard cron.
Reading the output critically
The converter describes fields independently, exactly as written. Real cron has one famous interaction: when both day-of-month and day-of-week are restricted, standard cron runs the job when EITHER matches, not both. The English sentence will not warn you about that, so an expression like 0 0 13 * 5 runs on the 13th of every month AND every Friday, not only on Friday the 13th.
Limitations
Cron dialects differ. Quartz and some cloud schedulers add seconds and year fields (six or seven fields), support special characters such as L, W, and #, or number weekdays differently; this converter accepts the standard five-field numeric syntax only and rejects other characters. Time zones and daylight-saving behavior belong to the scheduler and server, not the expression, so a 2:30 AM job can skip or double-fire around a clock change.
Nicknames and extended syntax you may meet elsewhere
Many schedulers accept nicknames such as @daily, @weekly, and @reboot, and extended dialects add a seconds field at the front, a year field at the end, or special letters: L for the last day of a month, W for the nearest weekday, and # for the nth weekday. This converter intentionally handles only the standard five numeric fields and will reject those extensions rather than guess at them, because each scheduler family interprets the extras slightly differently. If your expression uses them, convert the standard part here and then verify the extension against your own scheduler's documentation.
Cron or a calendar scheduler?
Cron is ideal for fixed, repeating times: nightly jobs, weekday reports, quarter-hour syncs. It is a poor fit for one-off future events, business-day-only logic with holiday calendars, or schedules tied to another system's state. For those, a calendar-based scheduler or a job queue with explicit next-run dates is easier to reason about than a clever cron expression nobody dares to edit. A useful rule: if the English translation of an expression takes more than one sentence, the schedule is too clever for cron.
The time-zone trap, in one scenario
A job written as 0 2 * * * on a server set to UTC runs at 2:00 AM UTC. For a team in Sydney that is midday, fine, until the requirement was "2 AM local". Nothing in the expression is wrong; the mismatch is between the expression and the scheduler's clock. Some schedulers offer a time-zone setting per job, others follow the host. After converting any expression, confirm which clock the host applies, and re-check after daylight-saving changes, because a fixed UTC offset quietly becomes the wrong local time twice a year.
Frequently Asked Questions
What does */5 in the minute field mean?
Every five minutes: the asterisk covers all values and the slash sets the step, so the job fires at minutes 0, 5, 10, and so on through 55.
Why did my expression get rejected?
It does not have exactly five fields, or it contains characters outside digits, asterisk, slash, comma, and hyphen, such as the Quartz-only L, W, ?, or # symbols.
Does cron know about time zones?
The expression itself does not. The scheduler applies the server or configured time zone, so confirm the host's zone before trusting a converted schedule.