Crontab to Human-Readable Translator
Paste a cron expression and read what it actually does in plain English.
Reviewed by the ToolNestr Editorial Team — July 2026
How cron-to-human translation works
A cron expression is a string of five space-separated fields that define a schedule: minute, hour, day of month, month, and day of week. Each field can contain a wildcard (*), a step value (*/n), a range (1-5), a list (1,3,5), or a fixed number. The parser reads each field independently and builds a plain-English sentence from the combined constraints.
Logic: how each field is interpreted
The five cron fields follow a strict order: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or JAN–DEC), and day of week (0–7 or SUN–SAT, where 0 and 7 both represent Sunday). Each field is parsed independently and the results are combined into a single sentence that describes all the constraints together.
The parser builds the English description by checking the specificity of each field. A wildcard (*) means "every" — it imposes no constraint. A fixed value means "at exactly this value." A range means "between X and Y." A step (*/n) means "every n units starting from 0." Lists combine multiple values with "and" or commas. The sentence is assembled as "At [minute] past [hour] on [days] in [months]" and then trimmed to remove redundant parts — for example, if all months are selected, the "in [months]" part is omitted.
Worked example: 30 2 * * 0
30
2
*
*
0
The parser reads 30 in the minute field — "at minute 30." The hour field 2 means "past hour 2" (02:30 in 24-hour time). The day-of-month and month fields are both wildcards, meaning "every day of every month." The day-of-week field 0 restricts to Sunday only. The combined result: "At 02:30, only on Sunday" or more naturally "At 02:30 every Sunday."
| Pattern | Meaning |
|---|---|
| * * * * * | Every minute |
| 0 * * * * | Every hour at minute 0 |
| 0 0 * * * | Every day at midnight |
| 0 0 * * 0 | Every Sunday at midnight |
| 30 2 * * * | Every day at 02:30 |
| */15 * * * * | Every 15 minutes |
| 0 9-17 * * 1-5 | Every hour 09:00–17:00 on weekdays |
| 0 0 1 * * | First day of every month at midnight |
| 0 0 * JAN,JUN * | Midnight every day in January and June |
| 0 0 * * 0,6 | Midnight every Saturday and Sunday |
| */10 9-17 * * 1-5 | Every 10 minutes during business hours on weekdays |
| 45 23 * * 5 | Every Friday at 23:45 |
Auditing existing cron jobs
When inheriting a server with dozens of cron jobs in the crontab, translating each expression to plain English helps you quickly understand what runs when without decoding five-field syntax manually.
Code review
During pull request reviews, cron expressions can be hard to spot-check. Paste them here to verify the intended schedule matches the code — no mental arithmetic needed.
Learning an inherited crontab
Taking over a system where the previous admin left cryptic cron entries? Translate them all to understand the maintenance schedule, backup timing, and batch job frequency.
Writing new cron expressions
When setting up a new scheduled task, type your intended cron expression and verify the English description matches what you want. Catch mistakes before they go into production.
Tips for working with cron expressions
Day-of-month vs day-of-week interactions
When both the day-of-month (3rd field) and day-of-week (5th field) are specified (neither is *), cron runs the job when either condition matches. For example, 0 0 15 * 5 runs at midnight on the 15th and every Friday — not only on Fridays that fall on the 15th. This is a common source of confusion. To run on a specific weekday of the month (e.g., the second Tuesday), you need to either use advanced syntax (like 0 0 8-14 * 2) or add a conditional check in your script.
Server timezone awareness
Cron uses the local timezone of the server. If your server is set to UTC and you intend a job to run at 9 AM Eastern Time, you need to subtract the UTC offset. For 9 AM EST (UTC-5), the expression would be 0 14 * * *. This is a frequent source of bugs when teams span multiple timezones. Consider setting your server to UTC and always converting intended times explicitly.
Special strings (@daily, @hourly, etc.)
Many cron implementations support shorthand strings like @daily (equivalent to 0 0 * * *), @hourly (0 * * * *), @weekly (0 0 * * 0), @monthly (0 0 1 * *), and @yearly (0 0 1 1 *). This tool expects standard 5-field numeric expressions — expand shorthands to their equivalent form before pasting.
Leap years and month lengths
Be careful with day-of-month values like 31 on months that have fewer days, or 29 on non-leap-year Februarys. Cron will silently skip those dates. If you set 0 0 31 * *, the job will not run in April, June, September, or November. Some cron implementations also handle 29 Feb differently in non-leap years (silently skipped). Always test edge dates when scheduling monthly jobs near month boundaries.
Common use cases for cron expression translation
Translating cron expressions to human-readable text is valuable whenever you encounter an unfamiliar crontab. System administrators reviewing a server for the first time often find a mix of legacy cron jobs with no documentation. Translating each expression reveals the maintenance schedule — backups at 2 AM, log rotation at midnight, report generation at 8 AM weekdays — without having to trace each script individually.
Developers working in teams benefit when cron expressions are included in configuration files, deployment scripts, or infrastructure-as-code repositories. A quick translation during code review ensures that 0 0 * * 0 was intended as "weekly" and not mistakenly written by someone who thought the day-of-week field was day-of-month. The same applies when debugging why a job ran unexpectedly — translating the expression is often the fastest way to spot the error.
DevOps engineers and SREs use cron translation during incident response. When a scheduled job runs at the wrong time or fails to run at all, checking the actual cron expression against the intended schedule is the first diagnostic step. Having a quick translator avoids mental parsing errors that can lead to misdiagnosis. It is also useful when migrating cron jobs between servers that might have different timezone settings — translating helps confirm the adjusted expression before deployment.
Students and new engineers learning Linux system administration find cron translation helpful as a learning tool. By experimenting with different field combinations, they develop an intuition for how the five fields interact. Typing */15 9-17 * * 1-5 and reading "every 15 minutes between 09:00 and 17:00, Monday through Friday" reinforces the field order and syntax rules much faster than memorizing reference charts.
How the parser handles different field patterns
The parser recognises several patterns within each field. A bare number like 5 means "exactly 5." A step like */15 means "every 15 starting from 0," which is equivalent to 0, 15, 30, and 45. A range like 9-17 means "every value from 9 to 17 inclusive." A list like 1,15,30 means "only at these specific values." Combinations like 1-5,10-15 are also supported.
Month and day names are case-insensitive. The parser accepts three-letter abbreviations (JAN, Feb, mar) and maps them to their numeric equivalents. Similarly, day names (SUN, Mon, tue) are mapped to 0–6. This means 0 0 * JAN * and 0 0 * 1 * produce the same result — "Midnight every day in January." The parser normalises these names before building the description, so the English output always uses the numeric values expressed as names (e.g., "January" not "1").
The next 5 run times feature computes upcoming execution times based on the parsed schedule and the current time. It tests candidate times minute by minute, checking each field's constraints, and collects the next 5 matches. This preview is especially useful for verifying that complex expressions behave as expected — for example, confirming that 0 0 31 * * will not fire in April because April has only 30 days. The next-run calculation is done entirely in the browser using the visitor's local time.
Security and privacy
All cron expression parsing happens in your browser. No data is sent to any server — the text you type never leaves your device. This means you can safely paste cron expressions from production systems without worrying about data leakage. There are no cookies, trackers, or analytics scripts associated with the translation functionality.
Related tools
Frequently asked questions
What does 0 0 * * * mean?
Every day at midnight.
What does */15 mean?
Every 15 units — e.g. every 15 minutes in the minute field.
Does it show the timezone?
It describes the schedule; actual time depends on your server timezone.
What if my cron has 6 fields?
Some cron versions have a 6th field for year — this parser handles the standard 5 fields.