Skip to main content
Home Tools Cron Expression Parser
🔧 Programming ✅ 100% Free ⚡ Instant

Cron Expression Parser & Builder

Paste a cron expression to get a plain-English explanation and the next 10 run times, or build one visually field by field. All processing happens in your browser using your local time zone.

Invalid cron expression
Minute0
Hour9
Day (Month)*
Month*
Day (Week)1-5
🗓️
Loading…
🛠️ Visual Builder
Minute
Hour
Day of Month
Month
Day of Week
⏭️ Next 10 Run Times (your local time)
⚡ Common Schedules
📖 Field Reference
FieldAllowedSpecial
Minute0-59* , - /
Hour0-23* , - /
Day of Month1-31* , - / ?
Month1-12* , - / JAN-DEC
Day of Week0-6 (0=Sun)* , - / SUN-SAT
⌨️ Syntax Cheatsheet
*Any value (every minute, every hour, etc.)
,Value list separator — e.g. 1,15,30
-Range of values — e.g. 1-5
/Step values — e.g. */15 = every 15
0 0 * * *Daily at midnight
@rebootRun once at startup (not all systems)

What is a Cron Expression?

A cron expression is a string of five fields used to schedule tasks to run automatically at specific times — minute, hour, day of month, month, and day of week. The cron daemon, found on virtually every Linux and Unix-like system, reads these expressions from a "crontab" file and executes the associated command when the schedule matches the current time. Cron expressions are also used in CI/CD pipelines (GitHub Actions, GitLab CI), Kubernetes CronJobs, and task schedulers across countless platforms.

This tool runs entirely in your browser — paste an expression to get an instant explanation, or build one visually field by field.

Cron Expression Format

A standard cron expression has five space-separated fields, in this order:

  • Minute (0–59) — which minute of the hour the task should run.
  • Hour (0–23) — which hour of the day, in 24-hour format.
  • Day of month (1–31) — which day of the calendar month.
  • Month (1–12 or JAN–DEC) — which month of the year.
  • Day of week (0–6 or SUN–SAT, where 0 and 7 both mean Sunday) — which day of the week.

Each field can contain a specific value, a wildcard * (meaning "every"), a range (1-5), a list (1,15,30), or a step value (*/15 meaning "every 15 units").

How to Use This Tool

  • Parse an expression — paste your cron string into the input field to see a plain-English explanation and the next 10 scheduled run times in your local time zone.
  • Build visually — use the visual builder below to construct an expression field by field without memorising syntax.
  • Use a preset — click any common schedule in the sidebar to load it instantly.
  • Copy and deploy — copy the final expression and paste it into your crontab, GitHub Actions workflow, or Kubernetes CronJob spec.

Frequently Asked Questions

Run crontab -e to open your personal crontab in the default editor. Add a line in the format * * * * * /path/to/command. Save and exit — cron picks up the change automatically, no restart needed. Use crontab -l to list your current cron jobs.
By default, cron uses the system's local time zone as configured on the server. This can cause confusion when servers are in UTC but you're thinking in your local time. Some systems support a CRON_TZ variable in the crontab to set a specific time zone for individual jobs. GitHub Actions cron schedules always run in UTC regardless of your local setting.
When both fields are restricted (not *), most cron implementations treat them as an OR — the job runs if EITHER condition is true. For example, 0 0 1,15 * 5 runs at midnight on the 1st, the 15th, AND every Friday. If you only want one condition, set the other field to * or use ? in systems that support it (like Quartz scheduler).
Cron is the traditional, simple scheduler available on virtually every Unix system. systemd timers are a more modern alternative on Linux distributions using systemd — they offer better logging (via journalctl), dependency management, and the ability to catch up on missed runs after a system was offline. Cron is simpler to set up for basic recurring tasks; systemd timers are better for complex service dependencies.
Common causes: (1) the cron service isn't running — check with systemctl status cron, (2) the script lacks execute permissions — run chmod +x script.sh, (3) the PATH environment variable is different in cron's minimal environment — use absolute paths to commands, (4) syntax errors in the crontab — check /var/log/syslog or /var/log/cron for errors, (5) the command outputs to stdout/stderr without redirection, causing mail delivery failures that mask the real error.
Yes — GitHub Actions workflows support a schedule trigger using standard cron syntax: on: schedule: - cron: '0 9 * * 1-5'. Note that GitHub Actions schedules always run in UTC, and scheduled workflows may be delayed during periods of high load on GitHub's infrastructure — they are not guaranteed to run at the exact specified minute.
Copied!