Cron Expression Generator with next run times

A cron expression generator you can read

This free cron expression generator turns a schedule into the five or six short fields that cron, Kubernetes, GitHub Actions and Quartz expect, and turns any expression back into plain English. Type an expression and the builder follows; click through the builder and the expression updates. You also see the next 10 run times in the time zone you pick, so you can confirm that "every weekday at 9" really means what you think before a job goes live.

The tool supports standard crontab syntax with 5 fields and the Quartz syntax used by Java schedulers, with seconds and an optional year. Everything is calculated in your browser.

Cron syntax in one table

* means every value, , separates a list (1,15), - is a range (9-17) and / is a step (*/15 is every 15th value starting at the lowest). Standard cron also accepts shortcuts: @hourly, @daily (same as @midnight), @weekly, @monthly, @yearly (same as @annually) and @reboot, which runs once at startup.

Common cron expression examples

• */5 * * * * - every 5 minutes.
• 0 * * * * - at the start of every hour.
• 30 9 * * 1-5 - at 09:30, Monday through Friday.
• 0 0 1 * * - at midnight on the first day of each month.
• 0 6,18 * * * - at 06:00 and 18:00 every day.
• 0 0 12 L * ? (Quartz) - at noon on the last day of each month.
• 0 0 9 ? * 2#1 (Quartz) - at 09:00 on the first Monday of each month.

Standard cron vs Quartz cron

Linux crontab, Kubernetes CronJobs and GitHub Actions use 5 fields with minute precision. Quartz, Spring and many Java and .NET schedulers add a seconds field at the front and an optional year at the end. Quartz also counts days of the week from 1 (Sunday) instead of 0, and it requires a ? in either day-of-month or day-of-week, because it will not combine the two. In exchange it offers handy specials: L for the last day of the month or the last Friday (6L), W for the nearest weekday (15W) and # for the nth weekday (2#2 is the second Monday). AWS EventBridge uses a Quartz-like 6-field format without seconds. Use the Convert button to switch dialects; the tool tells you when a schedule cannot be expressed in the other syntax.

The day-of-month and day-of-week trap

In standard cron, if you restrict both day fields, the job runs when either one matches. 0 0 1 * 1 runs on the 1st of every month and on every Monday, not only on Mondays that fall on the 1st. The generator warns you about this and shows the real run dates.

Time zones and daylight saving time

Cron runs in the time zone of the machine or service that executes it. GitHub Actions schedules are always UTC, Kubernetes accepts a timeZone field, and many cloud schedulers default to UTC. Pick a zone in the next-runs panel to see the schedule exactly as it will fire. Daylight saving time needs extra care: when clocks go forward, a local time such as 02:30 does not exist that day, and when they go back, 01:30 happens twice. Cron implementations handle this differently, so avoid scheduling important jobs between 01:00 and 03:00 local time, or run them in UTC.

Tips for reliable cron jobs

1. Write absolute paths and set the environment inside the script. Cron starts with a minimal PATH.
2. Log output: add >> /var/log/job.log 2>&1 so failures leave a trace.
3. Make jobs idempotent and prevent overlap (for example with flock) if a run can take longer than the interval.
4. Spread heavy jobs away from minute 0, when everyone else schedules theirs.
5. Add a comment above each line saying what the job does and who owns it.

Write the scripts your cron jobs call with help from the SQL query builder and README generator, or browse all free AI generators and tools.

FAQ