Explain cron expressions in plain English with field breakdown and scheduling summary.
Paste a cron expression like 0 9 * * 1-5 and this tool translates it into plain English — "At 09:00 AM, Monday through Friday" — and shows the next few times it will fire. It parses the five standard fields (minute, hour, day-of-month, month, day-of-week) plus step (*/5), range (1-5), and list (1,3,5) syntax, so you can verify a schedule before deploying it instead of waiting to see if the job runs. No account, no server round-trip.
150+ Free Tools No Signup Required JSON / CSV / Excel 30 Uses / Day
Quick answer
Paste a cron expression like 0 9 * * 1-5 and this tool translates it into plain English — "At 09:00 AM, Monday through Friday" — and shows the next few times it will fire. It parses the five standard fields (minute, hour, day-of-month, month, day-of-week) plus step (*/5), range (1-5), and list (1,3,5) syntax, so you can verify a schedule before deploying it instead of waiting to see if the job runs. No account, no server round-trip.
What is Cron Expression Explainer?
A cron explainer decodes cron expressions — the compact five-field schedules used by the Unix cron daemon, Kubernetes CronJobs, GitHub Actions, and most CI/CD and scheduling systems — into human-readable descriptions. Cron syntax is notoriously easy to misread: a single misplaced field can turn "every day at midnight" into "every minute of the midnight hour." This tool removes the guesswork by describing exactly when a schedule fires and listing upcoming run times.
How to use Cron Expression Explainer
1
Enter the cron expression
Type or paste a standard five-field cron string such as */15 * * * * or 0 0 1 * *. Common named shortcuts like @daily and @hourly are recognised too.
2
Read the plain-English translation
The tool describes the schedule in a sentence — for example "Every 15 minutes" or "At 00:00 AM, on day 1 of the month" — so you can confirm intent at a glance.
3
Check upcoming run times
See a list of the next several timestamps the expression will trigger, which catches subtle mistakes that the description alone might hide.
4
Adjust and re-verify
Tweak a field and watch the description and next-run list update, iterating until the schedule matches what you actually want before you commit it to crontab or a workflow file.
Try it when you need to…
Try it when you're staring at 0 2 * * 0 and can't remember if 0 means Sunday or Monday
Try it when a scheduled job is firing at an unexpected time and you need to see the actual next-run list
Try it before deploying a new crontab line so a typo doesn't run a heavy job every minute
Use cases
Verifying a backup job's schedule before adding it to crontab so it doesn't run at the wrong hour
Understanding a legacy cron entry you inherited with no documentation
Writing the schedule field for a Kubernetes CronJob or GitHub Actions workflow correctly the first time
Explaining to a non-technical teammate exactly when an automated report goes out
Debugging why a job fired more often (or less often) than expected
Key features
✓Translates all five standard cron fields into a readable sentence
✓Handles step (*/n), range (a-b), and list (a,b,c) operators
✓Lists the next several scheduled run times for verification
✓Recognises named shortcuts like @daily, @hourly, and @weekly
✓Instant client-side parsing with no login or upload
Tips & best practices
The classic trap is the day-of-month and day-of-week fields. When BOTH are set (not *), standard cron uses OR logic, not AND — so 0 0 13 * 5 runs on the 13th of the month AND on every Friday, not only Fridays that fall on the 13th.
Cron has no timezone of its own — it runs in the system's local timezone (or UTC in many container images). A schedule that says 0 9 * * * fires at 9 AM server time, which may not be 9 AM for your users. Set the container/host TZ explicitly or state times in UTC.
Standard Unix cron has five fields. Some systems (Quartz, AWS EventBridge, Spring) add a seconds field at the front or a year field at the end, making six or seven — a six-field expression pasted into plain cron will be misread.
Both 0 and 7 mean Sunday in the day-of-week field; the range is 0-6 or 1-7 depending on implementation, with Sunday appearing at both ends.
Frequently asked questions
From left to right they are minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). An asterisk in any field means "every" value for that field. So 30 8 * * 1 means "at 08:30 on Mondays."
Traditional Unix cron uses the system's local timezone as configured on the host — there is no timezone field in the expression itself. In Docker containers this often defaults to UTC unless you set the TZ environment variable. Because of this, the safest practice is to write schedules in UTC and document it, or explicitly configure the timezone your scheduler supports (some, like Kubernetes CronJobs v1.27+, add a spec.timeZone field).
It depends on the implementation. Classic Vixie cron runs jobs in local time, so during a spring-forward transition a job scheduled for 2:30 AM may be skipped, and during fall-back it may run twice. Running your scheduler in UTC avoids DST ambiguity entirely, which is why many teams standardise on UTC for cron.
The slash is a step operator. */5 in the minute field means "every 5th minute" — i.e. at minute 0, 5, 10, 15 and so on. You can combine it with a range too: 0-30/10 means every 10 minutes within the first half of the hour (0, 10, 20, 30).
When you specify both the day-of-month and day-of-week fields as non-asterisk values, standard cron treats them with OR logic: the job runs if EITHER condition matches. So 0 0 1 * 1 fires on the 1st of every month and on every Monday. To restrict to a specific weekday, leave day-of-month as * .
These are convenience aliases. @hourly equals 0 * * * *, @daily (or @midnight) equals 0 0 * * *, @weekly equals 0 0 * * 0, @monthly equals 0 0 1 * *, and @yearly equals 0 0 1 1 *. There's also @reboot, which runs a job once when the system starts rather than on a time schedule.
Standard Unix/Linux cron uses five fields. However, Quartz Scheduler (Java) and AWS EventBridge use six or seven fields by adding a leading seconds field and/or a trailing year field. If you paste a six-field Quartz expression into a five-field parser it will be misinterpreted, so always confirm which flavour your scheduler expects.