Cron Parser

What a cron expression is

A cron expression is a compact string that describes a repeating schedule. The name comes from Chronos (Greek for time) via the Unix cron daemon, which has been running scheduled jobs since Version 7 Unix in 1979. Operators write one expression and the scheduler figures out every future run time automatically.

The classic five-field format is:

┌───────── minute        (0–59)
│ ┌─────── hour          (0–23)
│ │ ┌───── day of month  (1–31)
│ │ │ ┌─── month         (1–12 or JAN–DEC)
│ │ │ │ ┌─ day of week   (0–7, both 0 and 7 are Sunday, or SUN–SAT)
│ │ │ │ │
* * * * *

This tool uses the cron-parser library to compute next run times and cronstrue to generate a plain-English explanation like "At 9:00 AM, Monday through Friday."

Field syntax

Each field accepts several syntactic forms:

• Wildcard * — matches every value. * * * * * runs every minute.
• Specific value — 30 * * * * runs at the 30-minute mark of every hour.
• Range — 1-5 means values 1, 2, 3, 4, 5. MON-FRI in the day-of-week field means weekdays.
• Step — */15 means "every 15th value": 0, 15, 30, 45 in the minute field. 1-10/2 means 1, 3, 5, 7, 9.
• List — comma-separated values: 0,15,30,45 in the minute field fires four times per hour.

Combining forms: 0 9-17 * * MON-FRI runs at the top of every hour from 9 AM to 5 PM on weekdays.

Standard cron vs Vixie cron vs Quartz

These three variants are common sources of confusion because they look identical but behave differently.

Standard/POSIX cron has the five fields above. Day-of-week 0 and 7 are both Sunday. No seconds field. This is what most Linux distributions ship with.

Vixie cron (named after Paul Vixie, who rewrote cron in 1987) adds several conveniences: step values, the @ shorthand aliases, and the behavior where if both day-of-month and day-of-week are specified (neither is *), the job runs when either condition is satisfied (a logical OR). This OR behavior surprises many developers. 0 0 1 * 1 does not mean "first Monday of the month" — it means "midnight on the 1st of any month or midnight on any Monday."

Quartz Scheduler (Java) adds a seconds field as the first field and a year field as an optional seventh field. A Quartz expression looks like 0 30 9 * * MON-FRI (six fields), where the leading 0 is seconds. It also introduces L (last), W (nearest weekday), # (Nth occurrence), and ? (no specific value, used to break the OR ambiguity between day-of-month and day-of-week). Quartz does not have the Vixie OR behavior — you use ? to explicitly mark whichever field you want ignored.

When debugging a schedule, always identify which variant your system uses.

The @ shorthand aliases

Most Vixie-cron-derived systems support these convenience aliases:

| Alias | Equivalent | Meaning | |---|---|---| | @yearly / @annually | 0 0 1 1 * | Once a year, midnight Jan 1 | | @monthly | 0 0 1 * * | Once a month, midnight on the 1st | | @weekly | 0 0 * * 0 | Once a week, midnight Sunday | | @daily / @midnight | 0 0 * * * | Once a day, midnight | | @hourly | 0 * * * * | Once an hour, at the top of the hour | | @reboot | — | Once at startup (not time-based) |

These are not valid in Quartz or some cloud platforms. GitHub Actions uses @yearly etc. in its schedule: trigger; Kubernetes CronJob does not support them — use the equivalent five-field form.

Debugging Kubernetes CronJobs

Kubernetes CronJobs use standard five-field cron syntax, evaluated in UTC. Common mistakes:

Missing runs. If your cluster's node clocks are skewed or a node was restarted, the CronJob controller may skip a run if the startingDeadlineSeconds window has passed. Check kubectl describe cronjob <name> for "Missed scheduled time" events.

Timezone confusion. Kubernetes CronJobs evaluate schedules in UTC. If you expect 0 9 * * * to fire at 9 AM local time, you will be surprised when clocks change. Kubernetes 1.27+ added the timeZone field to CronJob spec; on older clusters, add the UTC offset manually.

Concurrent runs. The concurrencyPolicy field defaults to Allow, meaning a new job starts even if the previous one is still running. For idempotent jobs this is fine; for jobs that touch shared state, set concurrencyPolicy: Forbid.

Debugging GitHub Actions schedules

GitHub Actions uses Vixie-style cron in the schedule: trigger, also evaluated in UTC. The minimum interval is every 5 minutes; schedules more frequent than that are rejected. There is also a known limitation where scheduled workflows on the default branch may be delayed by up to an hour during periods of high GitHub load. If your scheduled job must run with tight timing, consider a dedicated scheduler (AWS EventBridge, Google Cloud Scheduler) triggering the workflow via the API instead.

Daylight saving time gotchas

Cron expressions are typically evaluated against wall-clock time in the server's configured timezone. When DST transitions occur:

• Spring forward (e.g., 2:00 AM becomes 3:00 AM): any job scheduled between 2:00 and 3:00 AM is skipped entirely — that hour does not exist.
• Fall back (e.g., 3:00 AM becomes 2:00 AM): any job scheduled in the repeated hour may fire twice — once on each pass through that hour.

The safest practice is to schedule jobs at times that do not fall in the transition window (avoid 2:00–3:00 AM for US timezones). For critical jobs, schedule in UTC and accept that the wall-clock time shifts by one hour twice a year.

Privacy

Next-run computations happen entirely in your browser using the cron-parser and cronstrue libraries. No expressions are sent to a server.

Related tools

• Timezone Converter — convert the UTC run times shown here to your local wall-clock time.
• Timestamp Converter — convert Unix epoch timestamps output by cron logs into readable dates.

Why does 0 0 1 * 1 not mean "the first Monday of the month"?

In Vixie cron (used by most Linux systems), when both day-of-month and day-of-week are specified — neither is * — the scheduler fires when either condition is true, not both. So 0 0 1 * 1 means "midnight on the 1st of any month OR midnight on any Monday." To schedule the first Monday of the month you need a workaround: run daily on Mondays and check inside the script whether date +%d is between 1 and 7. Quartz Scheduler avoids this ambiguity with the ? placeholder.

What is the difference between cron-parser and Quartz cron?

Standard/Vixie cron has five fields: minute, hour, day-of-month, month, day-of-week. Quartz adds a seconds field at the start and an optional year field at the end, giving six or seven fields. Quartz also adds special characters: L (last day), W (nearest weekday), # (Nth weekday of month), and ? (unspecified). A Quartz expression 0 30 9 * * MON-FRI is not valid five-field cron — the leading 0 is seconds. Always check which variant your platform expects.

Does this tool support the @yearly, @daily etc. aliases?

Yes. The cronstrue and cron-parser libraries both recognise the standard @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly aliases. The parser translates them to their five-field equivalents before computing next runs. Note that @reboot has no time-based meaning and cannot produce next-run times — the tool will indicate this if you enter it.

How does DST affect cron schedules?

Cron evaluates schedules against wall-clock time in the daemon's configured timezone. During a spring-forward transition, the hour that "doesn't exist" is skipped — any job scheduled in that window will not run. During fall-back, the repeated hour may trigger a job twice. The safest mitigation is to schedule jobs in UTC, accepting that the local wall-clock time shifts by one hour twice a year.

Why is my Kubernetes CronJob not running at the expected local time?

Kubernetes CronJob schedules are always evaluated in UTC, regardless of the node's system timezone. If you expect 0 9 * * * to fire at 9 AM in Paris (UTC+1), you need 0 8 * * * in winter and 0 7 * * * in summer — or use the timeZone field available in Kubernetes 1.27+. The tool shows next runs in both UTC and your browser's local timezone to help you spot this offset.

What is the minimum interval for GitHub Actions scheduled workflows?

GitHub Actions enforces a minimum schedule interval of 5 minutes (*/5 * * * *). Schedules more frequent than that are silently rounded or rejected. Additionally, scheduled runs on the default branch may be delayed by up to an hour during periods of heavy load on GitHub's infrastructure. For time-critical triggers, use an external scheduler that calls the GitHub Actions API.

Can cron expressions handle sub-minute intervals?

Standard five-field cron cannot — the finest granularity is one minute. To run a task every 10 seconds you would need a different mechanism: a loop inside the job itself, a systemd timer with OnCalendar=*:*:0/10, or a job scheduler like Quartz (Java) that supports seconds-level scheduling. If you enter a Quartz-style six-field expression this tool will attempt to parse it as a Quartz expression and show the seconds field explicitly.

My cron job ran at the wrong time after a server migration — what should I check?

Three things in order: (1) Timezone — verify the new server's timedatectl or /etc/timezone matches the old one; (2) Clock sync — confirm ntpd/chronyd is running and the clock is accurate; (3) DST offset — if the migration happened around a clock-change weekend, the offset difference between the old and new server timezone setting may account for a one-hour shift. Always schedule critical jobs in UTC to eliminate timezone ambiguity entirely.