Cron expression explainer and validator.

A standard cron expression has five fields separated by spaces: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC) and day of week (0-7 or SUN-SAT, where both 0 and 7 mean Sunday). A job runs whenever the current minute matches all of them, subject to the day rule below.

Each field accepts * for every value, lists such as 1,15, ranges such as 1-5, and steps such as */15 or 9-17/2. The macros @yearly (or @annually), @monthly, @weekly, @daily (or @midnight) and @hourly are shorthands for common schedules.

This explainer follows the Vixie cron rules used by Linux crontab. It checks every field against its allowed range, explains the schedule in plain English, breaks it into its five fields and calculates the next five run times in your browser's time zone. If a schedule can never fire, it says so.

Field order is the most common mix-up: minute comes first, not hour. 9 0 * * * runs at 00:09, not at 9:00. Reading the plain-English line before you deploy catches this straight away.

A step means "every nth value within the range". */5 in the minute field is shorthand for 0-59/5, so it fires at minutes 0, 5, 10 and so on up to 55. It is anchored to the clock, not to when you saved the crontab: a job created at 10:03 first runs at 10:05.

Steps restart at every boundary. */7 in the minute field fires at 0, 7, 14 up to 56, then at 0 again, so the gap across the hour is only 4 minutes. If you need an exact interval that does not divide evenly into 60 minutes or 24 hours, cron cannot express it; use a timer-based scheduler instead.

Steps also work on ranges: 9-17/2 in the hour field means 9, 11, 13, 15 and 17.

When both day fields are restricted, standard cron runs on days that match either one, not both. 0 0 1 * 1 runs at midnight on the 1st of every month and also on every Monday, not only on Mondays that fall on the 1st. The explainer spells this out with an "or".

In Vixie cron, and in this tool, a day field that starts with * (such as */2) counts as unrestricted for this rule. To run on "the first Monday of the month", standard cron needs help: schedule 0 9 1-7 * * and have the job itself exit unless today is a Monday, or use a scheduler that supports the Quartz # syntax.

Not every "cron" is the same format. Linux crontab, Kubernetes CronJobs and GitHub Actions use the five standard fields this tool explains.

Quartz (common in Java schedulers) uses six or seven fields: seconds first, then the standard five, then an optional year. It requires ? in one of the two day fields, numbers days of the week 1-7 starting on Sunday, and adds L (last), W (nearest weekday) and # (nth weekday, as in 6#3 for the third Friday). Spring's @Scheduled cron also starts with a seconds field. AWS EventBridge uses six fields ending in a year, also with ? in one day field.

Pasting a six-field Quartz or Spring expression here gives "Expected 5 fields but found 6". Drop the leading seconds field (and any trailing year), and replace ? with *, to get the standard equivalent where one exists.

Cron itself has no idea of time zones; it uses whatever zone the scheduler runs in. A Linux crontab follows the server's system time zone, and some implementations accept a CRON_TZ variable. Kubernetes CronJobs use the controller's time zone unless you set the spec.timeZone field. GitHub Actions evaluates schedules in UTC by default and accepts an optional IANA timezone next to each cron entry. It also limits schedules to at most once every 5 minutes, and runs can start late when the platform is busy.

The next-run list on this page uses your browser's time zone, shown above it. If your scheduler runs in UTC, convert before you trust the times; the Unix timestamp converter helps.

Daylight-saving changes skip or repeat an hour in many regions, and implementations differ in how they handle jobs scheduled inside it. For critical jobs, schedule in UTC or avoid the local changeover hours.

The expression is often fine and the environment is not. Cron runs commands with a minimal PATH and no login shell, so use absolute paths to binaries and files. In a crontab line, an unescaped % is turned into a newline, so date +%F must be written date +\%F. Redirect output to a log file, otherwise errors vanish or go to local mail.

Within the expression itself, look for six fields copied from Quartz, a Quartz-only character such as ? or L, a range written backwards such as 5-1 (cron does not wrap ranges), or a date that does not exist, such as 0 0 30 2 *. This tool flags each of these.

Also guard against overlapping runs: if a job can take longer than its interval, wrap it in a lock (for example flock on Linux) or use a scheduler with a concurrency policy. In pipelines, scheduled jobs are a common part of CI/CD; our GitHub Actions CI/CD guide shows schedules alongside build workflows.