OnSumoTools

Visual Cron Schedule Builder

This tool builds, validates, and explains cron expressions directly in your browser. Enter a schedule in plain English or fill in the fields for minute, hour, day, month, and weekday, and the tool generates the cron expression with a human-readable description and a list of the next ten run times. No data is sent to a server. Your schedules and expressions stay on your device. The tool is free, requires no account, and works offline after the page loads.

GitHub Actions and most Linux crontabs use POSIX 5-field cron (minute hour day month weekday).

Valid schedule

At 09:00 Monday through Friday

Next 10 run times

  1. Friday, November 13, 2026 at 09:00:00 UTC
  2. Monday, November 16, 2026 at 09:00:00 UTC
  3. Tuesday, November 17, 2026 at 09:00:00 UTC
  4. Wednesday, November 18, 2026 at 09:00:00 UTC
  5. Thursday, November 19, 2026 at 09:00:00 UTC
  6. Friday, November 20, 2026 at 09:00:00 UTC
  7. Monday, November 23, 2026 at 09:00:00 UTC
  8. Tuesday, November 24, 2026 at 09:00:00 UTC
  9. Wednesday, November 25, 2026 at 09:00:00 UTC
  10. Thursday, November 26, 2026 at 09:00:00 UTC

Schedule math runs in your browser. Cron strings are not sent to a server.

How does the Cron Schedule Builder work step by step?

Cron expressions have five required fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). Each field accepts specific syntax. An asterisk (*) means "every value" (run every minute, every hour). A number means "this exact value" (run at 9 AM). A comma separates multiple values (1,15 means the 1st and 15th). A hyphen defines a range (1-5 means Monday through Friday). A slash specifies intervals (*/15 means every 15 units).

What does a typical Cron Schedule Builder result look like?

A GitHub Actions job should run at 09:00 UTC on weekdays. Choose the weekday preset, confirm the next runs list only Monday through Friday, then copy 0 9 * * 1-5 into your workflow file.

Frequently asked questions

  • What is the difference between day of month and day of week in cron?

    Day of month (field 3) targets specific calendar dates (1-31). Day of week (field 5) targets days like Monday or Friday (0-6). If both are set to non-wildcard values, the task runs when either condition is true (logical OR), not both. This is a common source of confusion.

  • How do I schedule a task to run every 30 minutes?

    Use */30 in the minute field and * in the hour field. The full expression is */30 * * * *. This runs at :00 and :30 of every hour. For tasks that should run at specific offsets (e.g., :15 and :45), use 15,45 * * * *.

  • Can I schedule a task to run on the last day of every month?

    Standard cron does not support "last day of the month" directly because months have different lengths. Some extended cron systems (like Quartz) support L in the day field, meaning "last." For standard cron, you must use separate expressions for 28, 29, 30, and 31, or write a script that checks if tomorrow is a new month.

  • What does the cron expression 0 0 1 1 * mean?

    It means "at midnight (0:00) on January 1st every year." The fields are: 0 minutes, 0 hours, 1st day of the month, 1st month (January), any day of the week (*). This is a yearly task.

  • How do I run a cron task every 5 minutes during business hours only?

    Use */5 9-17 * * 1-5. This breaks down as: every 5 minutes (*/5), between 9 AM and 5 PM (9-17), every day of the month (*), every month (*), Monday through Friday (1-5). The task will not run on weekends or outside 9-5.

  • Do cron expressions account for daylight saving time changes?

    Cron uses the system's local time. When clocks spring forward, a 2:30 AM task might be skipped (2 AM jumps to 3 AM). When clocks fall back, the task might run twice (2 AM happens twice). Use UTC-based cron to avoid this, or schedule around the 2 AM DST transition hour.

Cron without the guesswork

A cron expression is five fields squeezed into a short string. Minute, hour, day of month, month, day of week. It's compact, and it's easy to get wrong. One misplaced star and your backup runs every minute instead of every night.

The builder lets you set each field with controls, then writes the expression and explains it in plain English. It also lists the next ten run times so you can check the schedule before you trust it.

Reading the five fields

From left to right: minute, hour, day of the month, month, day of the week. A star means every value. A slash sets a step, so */15 in the minute field means every fifteen minutes. A dash gives a range and a comma gives a list.

Take 0 0 1 1 *. Minute 0, hour 0, first day, first month, any weekday. That's midnight on January 1st, once a year.

Common schedules

Presets cover the usual ones, and you can tweak them from there. Every 30 minutes is */30 * * * *. Every five minutes during business hours is */5 9-17 * * 1-5, which also limits it to weekdays.

The last day of every month is trickier. Standard cron has no clean way to say it. A common trick is to run on days 28 to 31 and let the script check whether tomorrow is the first. Some cron flavors add a special symbol for it, so check what your system supports.

Day of month versus day of week

This one catches people out. If you set both fields to something other than a star, many cron implementations run the job when either one matches, not when both do. So 0 9 15 * 1 fires on the 15th and also on every Monday. If you want only Mondays, leave day of month as a star.

Time zones and daylight saving

A cron expression has no time zone of its own. The server's clock decides. When clocks change for daylight saving, a job set inside the skipped hour may not run, and a job in the repeated hour may run twice. Many teams set servers to UTC to avoid the whole problem.

Test before you deploy

Look at the next ten run times. If they match what you meant, copy the expression. If the dates look strange, adjust and check again. It takes ten seconds and saves a missed backup or a flood of emails.