Few people read */15 9-18 * * 1-5 and immediately think 'every 15 minutes between 9am and 6pm on weekdays'. Cron expressions pack five fields (six if you include seconds) into whitespace-separated symbols, which makes them hard to verify by eye — and a misplaced asterisk turns a nightly job into one that runs 1,440 times a day.
This tool explains the expression in plain English as you type and computes the next ten real run times against an actual calendar, complete with weekday labels. Subtle mistakes — confusing 'the 1st of the month' with 'every Monday' — become obvious immediately. Build expressions field by field, or start from a preset for the schedules everyone needs.
How to use
- Type an expression or pick a preset — Enter a cron expression in the top field or click one of the presets (
0 0 * * *,30 9 * * 1-5and so on). The human-readable description updates as you type. - Refine field by field — Adjust minute, hour, day-of-month, month and day-of-week in the builder. The example chips next to each field (
*,*/5,1-5) apply instantly, and the grey text shows the legal range for that field. - Check the next run times — The right panel lists the next ten executions with weekdays. Times use your browser's timezone, so if your server runs in UTC you need to account for the offset. Daylight saving transitions are handled automatically.
- Switch to six fields when you need seconds — Schedulers like Spring and Quartz expect a leading seconds field. Toggle 6 fields (sec) and a seconds field is prepended to your existing expression.
Frequently asked questions
Which timezone are the run times in?
Your browser's timezone, shown next to the field-count toggle (for example Asia/Seoul).
Most production cron daemons run in UTC. If you write 0 9 * * * thinking 'nine in the morning' but your server is on UTC, the job fires at 9am UTC — which may be the middle of the night for you. Check the server's TZ environment variable or the scheduler's timezone setting before you deploy, and recompute in UTC if needed.
What happens if I set both day-of-month and day-of-week?
In standard crontab the two fields are combined with OR, not AND. This is the single most misunderstood rule in cron.
0 0 1 * 1 does not mean 'the 1st, but only if it's a Monday'. It means 'the 1st of the month or every Monday', which fires far more often than intended. Use one field and leave the other as *. The run-time list makes this mistake visible right away.
Are aliases like `@daily` and extensions like `L` or `#` supported?
The aliases @yearly, @monthly, @weekly, @daily and @hourly are parsed.
L (last day), W (nearest weekday) and # (nth weekday) are non-standard extensions supported only by Quartz-family schedulers. This tool attempts to parse them, but always confirm against your target scheduler's documentation — plain Linux crontab does not implement them.
Concepts worth knowing
What the five fields mean
Standard cron reads minute hour day-of-month month day-of-week. Each field accepts a number, a range (9-18), a list (1,15), a step (*/5), a wildcard (*), or a combination (0,30 9-18/2 * * *).
Day-of-week runs 0–6 with 0 as Sunday. Many implementations also accept 7 for Sunday and three-letter abbreviations like MON and FRI; the month field accepts JAN through DEC. For portability, numbers are the safer choice.
What cron does not guarantee
Cron promises only to start a process at a given time. It does not check whether the previous run finished, so a job scheduled every five minutes that takes seven will pile up overlapping instances. Guard against that yourself with flock or an application-level distributed lock.
Runs that fall while the machine is off are simply skipped. If missed work must be caught up, you need anacron or your own record of the last successful run.
Thundering herds on short intervals
*/5 * * * * fires at exactly the same instant on every machine that has it. With dozens of instances, that means a traffic spike against your database or a third-party API every five minutes.
In practice teams stagger the offsets (3,8,13,18,...) or add a short random delay at the start of the job. As a service grows, that small difference is often what separates a smooth deploy from an incident.