Cron Expression Generator

Cron fields: minute, hour, day-of-month, month, weekday

Cron is five (or six with seconds) independent fields; daylight saving can shift wall-clock triggers—prefer UTC for infra tasks when possible.

Validate expressions in staging; some platforms use quartz extensions incompatible with vanilla cron.

Reading a cron expression

┌───────── minute (0–59)
│ ┌─────── hour (0–23)
│ │ ┌───── day of month (1–31)
│ │ │ ┌─── month (1–12)
│ │ │ │ ┌─ day of week (0–6, Sunday = 0)
│ │ │ │ │
0 9 * * 1-5   → 09:00, Monday to Friday

Each field accepts * (every value), a single number, a list (1,15), a range (9-17) or a step (*/15). The builder writes these for you and shows a plain-English description of the schedule, so you can confirm it before pasting it into crontab or a CI configuration.

Worked examples

• */15 9-17 * * 1-5 — every 15 minutes from 09:00 to 17:45, weekdays only (the last run is 17:45 because the hour field stops at 17).
• 30 2 * * 0 — 02:30 every Sunday, a common slot for weekly maintenance.
• 0 0 1 * * — midnight on the first day of every month, for monthly reports.
• 0 9,18 * * * — 09:00 and 18:00 every day.
• 0 0 1 1 * — once a year at midnight on 1 January.

Gotchas that cause missed or duplicate runs

• Day of month OR day of week: when both fields are restricted, standard cron runs when either one matches. 0 0 13 * 5 runs on every 13th and on every Friday, not only on Friday the 13th.
• Uneven steps: */7 in the minute field runs at :00, :07 … :56 and then :00 again, leaving a 4-minute gap each hour. Steps only divide evenly when they are factors of 60 (minutes) or 24 (hours).
• Daylight saving time: in a local time zone, jobs scheduled between 01:00 and 03:00 can be skipped or run twice on the nights the clocks change, depending on the cron implementation. Schedule critical jobs in UTC or outside that window.
• Time zone of the server: crontab uses the machine’s time zone; GitHub Actions schedules always run in UTC; Kubernetes CronJobs can set an explicit timeZone.
• Last day of the month: standard cron has no syntax for it. Run daily on the 28th–31st and check in the script whether tomorrow is the 1st.

Cron dialects

• Standard (Vixie) cron and most Linux systems: the five fields shown here. Many also accept 7 for Sunday and three-letter names (MON, JAN).
• Quartz (Java) and Spring: six or seven fields, starting with seconds, and ? for “no specific value” in day-of-month or day-of-week.
• AWS EventBridge: six fields including a year, and one of the two day fields must be ?.
• GitHub Actions: standard five fields in UTC, with runs no more often than every 5 minutes and possible delays at busy times.

Paste the five-field output from this tool as-is into crontab, GitHub Actions or Kubernetes; for Quartz or EventBridge, add the extra fields their syntax requires.

Making a cron job run reliably

• Run the command by hand first, as the same user cron will use.
• Use absolute paths: cron starts jobs with a minimal environment and a short PATH, so commands that work in your shell may not be found.
• Capture output, e.g. 0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1, otherwise errors are mailed to a local mailbox nobody reads, or lost.
• Prevent overlaps for long jobs with a lock, for example flock -n /tmp/backup.lock /usr/local/bin/backup.sh.