Cron Expression Parser

Parse cron expressions into human-readable descriptions and preview next run times

Try an example

Cron expression

minute hour day(month) month day(week)

Human-readable description

At 9:00 AM, Mon, Tue, Wed, Thu, Fri

Field breakdown

Minute

0

0–59

Hour

9

0–23

Day (month)

*

1–31

Month

*

1–12

Day (week)

1-5

0–6

Next 10 scheduled runs

12026-03-26 09:00:00
22026-03-27 09:00:00
32026-03-30 09:00:00
42026-03-31 09:00:00
52026-04-01 09:00:00
62026-04-02 09:00:00
72026-04-03 09:00:00
82026-04-06 09:00:00
92026-04-07 09:00:00
102026-04-08 09:00:00

What Is Cron Expression Parsing?

A cron expression is a string of five fields separated by spaces that defines a recurring schedule. The format originated in the Unix cron daemon, first written by Ken Thompson for Version 7 Unix in 1979. Each field represents a time unit: minute, hour, day of the month, month, and day of the week. Parsing a cron expression means converting this compact notation into a human-readable description and a concrete list of upcoming execution times.

The standard five-field format is used by crontab on Linux and macOS, by CI/CD platforms like GitHub Actions and GitLab CI, by cloud schedulers in AWS (EventBridge), Google Cloud Scheduler, and Azure Functions, and by job-scheduling libraries in every major programming language. Some systems extend the format to six or seven fields by adding a seconds field or a year field, but the five-field layout defined by POSIX remains the baseline that all implementations share.

Parsing cron expressions by hand is error-prone. The interaction between fields creates non-obvious schedules: 0 9 1-7 * 1 does not mean 'every Monday in the first week' but rather 'the 1st through 7th of every month OR any Monday.' A cron parser eliminates this ambiguity by expanding each field, applying the combination rules, and producing the actual timestamps when the job will fire.

Why Use This Cron Parser?

Reading a cron expression like 30 */6 1,15 * * from a config file and knowing exactly when it fires requires mental arithmetic across five fields. This parser does that work instantly.

⚑
Instant Parsing
Type or paste a cron expression and see the human-readable description and the next 10 scheduled run times immediately. No submit button, no reload.
πŸ”’
Privacy-first Processing
All parsing runs locally in your browser. Your cron expressions and schedule data never leave your device.
πŸ“‹
Field-by-field Breakdown
Each of the five fields is parsed and displayed individually, showing the resolved values. Spot which field controls the schedule at a glance.
πŸ”„
No Account Required
Open the page and start parsing. No login, no API key, no installation. Works on any device with a modern browser.

Cron Parser Use Cases

Frontend Developer
Verify cron expressions in admin dashboards and scheduling UIs before sending them to the backend. Confirm that the schedule a user selected in a dropdown matches the cron string generated by the form.
Backend Engineer
Debug scheduled jobs that fire at unexpected times. Paste the cron expression from your task queue config (Celery, Sidekiq, Quartz) and check whether the next run times match what you expect.
DevOps / SRE
Audit cron schedules in CI/CD pipelines, Kubernetes CronJobs, and cloud scheduler configs. Verify that backup jobs, certificate renewals, and cleanup scripts are timed correctly before deploying.
QA Engineer
Validate that scheduled tasks in the test environment match the production schedule. Catch off-by-one errors in month or day-of-week fields before they cause missed runs in prod.
Data Engineer
Check the cron triggers for ETL pipelines and data sync jobs. Confirm that extraction windows do not overlap and that downstream dependencies have enough lead time.
Student / Learner
Learn cron syntax by experimenting with different expressions and seeing the results in real time. Build intuition for how wildcards, ranges, and step values interact.

Cron Expression Syntax Reference

A standard cron expression has five space-separated fields. Each field accepts integers, wildcards, ranges, lists, and step values. The table below shows the allowed range and operators for each field.

FieldRangeOperatorsDescription
Minute0–59* , - /Minute within the hour
Hour0–23* , - /Hour of the day (24-hour)
Day (month)1–31* , - /Day of the month
Month1–12* , - /Month of the year (or JAN–DEC)
Day (week)0–6* , - /Day of the week (0 = Sunday, or SUN–SAT)

Four special characters control how values are matched within each field:

CharNameBehavior
*WildcardMatches every possible value in the field. * in the minute field means "every minute."
,ListSeparates individual values. 1,15 in the day field means "the 1st and 15th."
-RangeDefines an inclusive range. 1-5 in the day-of-week field means "Monday through Friday."
/StepDefines an interval. */10 in the minute field means "every 10 minutes." 5/15 means "5, 20, 35, 50."

Here are common cron expressions that cover most scheduling needs:

ExpressionSchedule
* * * * *Every minute
0 * * * *Every hour (at minute 0)
*/15 * * * *Every 15 minutes
0 9 * * *Every day at 9:00 AM
0 9 * * 1-5Weekdays at 9:00 AM
30 2 * * 0Every Sunday at 2:30 AM
0 0 1 * *First day of every month at midnight
0 0 * * 1Every Monday at midnight
0 0 1 1 *January 1st at midnight (yearly)
0 */6 * * *Every 6 hours
5,35 * * * *At minute 5 and 35 of every hour
0 9-17 * * 1-5Every hour from 9 AM to 5 PM, weekdays

Code Examples

How to parse cron expressions and calculate next run times in popular languages:

JavaScript (Node.js)
import cronstrue from 'cronstrue';

// Parse cron to human-readable text
cronstrue.toString('0 9 * * 1-5');
// β†’ "At 09:00 AM, Monday through Friday"

cronstrue.toString('*/15 * * * *');
// β†’ "Every 15 minutes"

// Validate with cron-parser and get next run times
import { parseExpression } from 'cron-parser';

const interval = parseExpression('30 2 * * 0');
console.log(interval.next().toISOString());
// β†’ next Sunday at 02:30 UTC

// Iterate over the next 5 runs
for (let i = 0; i < 5; i++) {
  console.log(interval.next().toString());
}
Python
from crontab import CronTab
from croniter import croniter
from datetime import datetime

# Parse and describe a cron expression
cron = CronTab('0 9 * * 1-5')
print(cron.next(default_utc=True))
# β†’ seconds until next run

# Get the next 5 run times with croniter
base = datetime.now()
cron_iter = croniter('0 9 * * 1-5', base)
for _ in range(5):
    print(cron_iter.get_next(datetime))
# β†’ next 5 weekday 09:00 timestamps

# Check if a specific time matches
print(croniter.match('*/15 * * * *', datetime(2026, 3, 25, 10, 30)))
# β†’ True (minute 30 is divisible by 15)
Go
package main

import (
    "fmt"
    "time"
    "github.com/robfig/cron/v3"
)

func main() {
    // Parse a standard 5-field cron expression
    parser := cron.NewParser(cron.Minute | cron.Hour | cron.Dom | cron.Month | cron.Dow)
    schedule, err := parser.Parse("0 9 * * 1-5")
    if err != nil {
        panic(err)
    }

    // Calculate the next 5 run times
    now := time.Now()
    for i := 0; i < 5; i++ {
        now = schedule.Next(now)
        fmt.Println(now)
    }
    // β†’ next 5 weekday 09:00 timestamps
}
Bash (crontab)
# List current user's cron jobs
crontab -l

# Edit cron jobs interactively
crontab -e

# Add a job: run backup.sh every day at 2:30 AM
# (append to crontab via pipe)
(crontab -l 2>/dev/null; echo "30 2 * * * /home/user/backup.sh") | crontab -

# Check syntax with a dry-run parse (requires cronie or busybox)
# The system will reject invalid expressions when saving

# View cron logs on systemd-based Linux
journalctl -u cron --since "1 hour ago"

Frequently Asked Questions

What is the difference between 5-field and 6-field cron expressions?
The standard (POSIX) cron format has 5 fields: minute, hour, day-of-month, month, day-of-week. Some tools like Quartz Scheduler and Spring add a seconds field at the beginning, making it 6 fields. AWS EventBridge uses 6 fields with a year field at the end. This parser supports the standard 5-field format, which is compatible with crontab, GitHub Actions, Kubernetes CronJobs, and most scheduling libraries.
How does cron handle day-of-month and day-of-week together?
When both fields are restricted (not *), cron uses OR logic: the job runs when either condition is true. For example, 0 9 15 * 1 means 'at 9:00 AM on the 15th of every month OR on every Monday.' This is a common source of confusion. If both fields are set to *, the job runs every day.
What timezone does cron use?
Traditional crontab runs in the system's local timezone. Kubernetes CronJobs default to the kube-controller-manager timezone (usually UTC) but support an optional .spec.timeZone field since Kubernetes 1.25. AWS EventBridge and Google Cloud Scheduler let you specify the timezone per schedule. Always check which timezone your scheduler uses before deploying a cron job.
Can cron run a job every 30 seconds?
Standard 5-field cron does not support sub-minute scheduling. The smallest interval is one minute (*/1 or *). To run something every 30 seconds, you need either a 6-field cron with a seconds field (Quartz, Spring), a wrapper script that sleeps 30 seconds and runs again, or a different scheduling mechanism like systemd timers with OnCalendar.
Is 0 the same as 7 for the day-of-week field?
In most cron implementations, both 0 and 7 represent Sunday. This convention comes from the original Unix cron. However, some systems (Quartz) use 1 for Sunday and 7 for Saturday. POSIX defines the range as 0-6 with 0 = Sunday. If your scheduler accepts named days (SUN, MON), use those to avoid ambiguity.
What happens if I set a day-of-month that does not exist?
If you schedule a job for the 31st (0 0 31 * *), it will not run in months with fewer than 31 days. Cron does not carry over to the next month. February will always be skipped, and April, June, September, and November will also be skipped. To run on the last day of every month, some cron implementations support the L modifier (0 0 L * *), but standard POSIX cron does not.
How do I test a cron expression before deploying it?
Use an online parser like this one to see the next run times and verify the schedule matches your intent. For production validation, most cron libraries provide a next-run calculation function: cron-parser in Node.js, croniter in Python, robfig/cron in Go. Run the expression through one of these in your test suite to assert the next N execution times before deploying.