Cron Expression Generator

Build a cron schedule by choosing minutes, hours, days, months and weekdays — or paste an existing crontab line — and see it explained in plain English with the next ten run times. Supports lists, ranges, steps, month and weekday names and the @daily-style shortcuts.

How cron expressions work

Cron is the time-based job scheduler on Unix-like systems, and its five-field syntax is also used by many cloud schedulers, CI pipelines and application frameworks. Each line tells cron when to run a command. The five fields, separated by spaces, are:

The job runs whenever the current time matches every field. So 30 8 * * 1-5 means “at 08:30 on Monday through Friday”.

Special characters

Shortcuts such as @hourly, @daily, @weekly, @monthly and @yearly are accepted by many cron implementations and are expanded by this tool into their five-field equivalents.

The day-of-month and day-of-week rule

One detail catches many people out. When both the day-of-month and day-of-week fields are restricted (neither is *), standard cron runs the job when either matches, not both. 0 9 1 * 1 runs at 09:00 on the 1st of every month and on every Monday. To run only on Mondays that fall on the 1st, you need a check inside the script. The explanation and next-run list on this page follow this standard behaviour.

Worked examples

Time zones

Classic cron uses the system time zone of the server it runs on. Many cloud schedulers — for example in container platforms and serverless services — run cron in UTC unless you configure otherwise. The next-run list can show times in your own time zone or in UTC; if your job runs on a server, choose the zone the server uses. Watch out for daylight saving time: a job scheduled at 02:30 may run twice or not at all on the night the clocks change in some regions.

Cron dialects

This tool follows standard five-field Unix cron. Some systems extend it: Quartz and Spring use six or seven fields with seconds (and optional years) at the front and allow ?, L, W and #; AWS EventBridge uses six fields including year; Jenkins adds H for hashed spreading. If you are writing for one of those systems, check its documentation — the core ideas of lists, ranges and steps are the same.

Crontab tips

• Use absolute paths in commands; cron runs with a minimal environment and PATH.
• Redirect output to a log file: command >> /var/log/job.log 2>&1.
• Avoid scheduling many jobs at exactly minute 0; spread them to reduce load spikes.
• Use a lock (for example flock) if a job might still be running when the next one starts.
• Edit with crontab -e and list with crontab -l; the last line should end with a newline.
• Test the command manually as the same user before scheduling it.

Scheduling patterns that scale

As the number of scheduled jobs grows, a few patterns keep things manageable. Keep one inventory listing every job, its schedule, owner and purpose. Stagger heavy jobs so backups, report generation and data imports do not all start at 02:00. Prefer idempotent jobs that can safely run twice, so a retry after a failure causes no harm. For tasks that must run exactly once across several servers, use a scheduler that supports distributed locking rather than identical crontabs on every machine. And alert on failure and on silence: a job that stops running quietly is harder to notice than one that errors.

Debugging a job that does not run

If a scheduled job never seems to run, check the basics in order: is the cron service running; is the expression what you think (paste it here to confirm the next run times); does the command work when run by hand as the same user; does it rely on environment variables or a working directory that cron does not provide; and is its output being discarded? Adding a line that writes the date to a log file at the start of the script quickly shows whether cron is starting it at all, which separates scheduling problems from script errors.