Cron Expression Parser

Introduction

Cron is a time-based job scheduler originally developed for Unix-like operating systems. The name comes from the Greek word "chronos" meaning time. Cron enables system administrators, developers, and DevOps engineers to automate repetitive tasks by scheduling commands or scripts to run at specific times or intervals. It is one of the oldest and most widely used scheduling tools, present in virtually every Linux and macOS system, and available on Windows through ports like Cron for Windows or via the Windows Subsystem for Linux.

A cron expression is a string composed of five fields that define when a job should execute. These fields represent the minute, hour, day of the month, month, and day of the week. Each field accepts a variety of syntax patterns including wildcards (*), exact values, ranges (1-5), step values (*/5), and comma-separated lists (1,3,5). While the five-field format is the most common standard, some implementations extend it with a sixth field for seconds or a seventh for years.

This parser helps you understand exactly when a given cron expression will fire. Instead of deploying a cron job and waiting to see if it runs at the expected time, you can enter the expression into this tool and immediately see the next ten, fifteen, or twenty execution times. This is invaluable for debugging complex schedules, verifying that time-sensitive tasks run when intended, and learning how cron syntax works in practice.

How to Use

Enter a standard five-field cron expression into the text input, set the number of future run times you want to see (between 1 and 20), and click "Next Run Times". The tool will display the upcoming execution moments formatted with weekday, date, and time.

Run #1: Mon, Jun 16 2026, 09:00:00 AM
Run #2: Mon, Jun 16 2026, 09:05:00 AM
Run #3: Mon, Jun 16 2026, 09:10:00 AM
Run #4: Mon, Jun 16 2026, 09:15:00 AM
Run #5: Mon, Jun 16 2026, 09:20:00 AM

Run #1: Mon, Jun 16 2026, 09:00:00 AM
Run #2: Tue, Jun 17 2026, 09:00:00 AM
Run #3: Wed, Jun 18 2026, 09:00:00 AM

Run #1: Tue, Jul 1 2026, 12:00:00 AM
Run #2: Sat, Aug 1 2026, 12:00:00 AM
Run #3: Tue, Sep 1 2026, 12:00:00 AM

Run #1: Sun, Jun 21 2026, 04:30:00 AM
Run #2: Sun, Jun 28 2026, 04:30:00 AM
Run #3: Sun, Jul 5 2026, 04:30:00 AM

Cron Syntax Reference

A standard cron expression consists of five whitespace-separated fields:

Reference Table

Practical Tips

1. Test cron expressions before deployment. A mistyped cron expression can cause jobs to run at the wrong time — or worse, never run at all. Use this parser to verify your expression produces the expected execution times before adding it to a crontab file. Always test with a count of at least 5 to spot unexpected scheduling patterns.

2. Be explicit about timezone handling. Cron runs on the system's local time by default. If your server is in UTC but your users are in Eastern Time, a schedule like 0 9 * * * fires at 9 AM UTC (which might be 5 AM or 4 AM depending on daylight saving). Always document which timezone your cron jobs use, and consider running critical jobs during UTC business hours for consistency across regions.

3. Redirect output to logs. Cron jobs run non-interactively — you will not see errors on a terminal. Always redirect stdout and stderr to a log file: 0 * * * * /path/to/script.sh >> /var/log/script.log 2>&1. Many systems also send cron output via email to the crontab owner, but relying on email for monitoring is unreliable in production environments.

4. Use absolute paths. Cron runs with a minimal environment. The PATH variable inside a cron job is often just /usr/bin:/bin. Always use absolute paths for commands and scripts, or set PATH explicitly at the top of your crontab: PATH=/usr/local/bin:/usr/bin:/bin. The same applies to environment variables like HOME and SHELL.

5. Watch for daylight saving time shifts. Cron handles daylight saving transitions in a system-dependent way. On most Linux distributions using UTC, DST has no effect. If the system clock follows local time, jobs scheduled between 2-3 AM may run twice on the "fall back" day or not at all on the "spring forward" day. For critical hourly jobs, consider scheduling at the half-hour mark (30 * * * *) to avoid the switch window.

6. Avoid resource contention. If multiple cron jobs are scheduled at the same minute (e.g., 0 * * * * for a dozen scripts), they all launch simultaneously, potentially overwhelming the system. Stagger related jobs by a few seconds or minutes: use 1 * * * *, 2 * * * *, etc., to distribute the load. This is especially important for database backups and report generation.

Limitations

This parser implements standard five-field cron expressions as defined by the POSIX standard and used by Vixie cron (the most common implementation). It does not support the extended six-field format (with leading seconds) or seven-field format (with trailing year) used by some cron variants like Quartz, Spring, or AWS Lambda cron expressions.

The parser also does not support named special strings such as @reboot, @yearly, @monthly, @weekly, @daily, or @hourly that some cron implementations support as shorthand. To replicate @yearly, use 0 0 1 1 *; for @hourly, use 0 * * * *.

The day-of-month and day-of-week logic follows standard cron OR semantics. If both fields contain restricted values (e.g., 0 0 15 * 3), the job fires when either condition is true, not only when both are true simultaneously. This is a common source of confusion and is inherent to the cron specification rather than a limitation of this parser.

All calculations use the browser's local timezone as reported by Date. This parser does not support timezone selection or UTC mode. For timezone-aware scheduling, consider converting your expression to the server's timezone before testing.

The maximum search horizon is one year (525,600 minutes). If the cron expression matches less frequently than once per year (e.g., 0 0 29 2 * for February 29th in a non-leap year), the parser may return no results. Increase the count setting does not extend the search window.

Frequently Asked Questions

What does */5 in a cron expression mean?

The */5 syntax means “every 5 units” starting from the minimum value of the field. In the minute field (0-59), */5 means minutes 0, 5, 10, 15, and so on — effectively running every 5 minutes. In the hour field (0-23), */6 means 0, 6, 12, 18 — every 6 hours.

What is the difference between 0 and 7 in the weekday field?

Both 0 and 7 represent Sunday in standard cron. Sunday is the only day with two valid values. This historical quirk exists because some implementations number weekdays from 0 (Sunday=0, Monday=1) while others number them from 1 (Sunday=7, Monday=1). Most modern systems accept both.

How do I schedule a job for every 30 minutes?

Use */30 in the minute field with * for the other four fields: `*/30 * * * *`. This runs at minute 0 and minute 30 of every hour. For every 30 minutes during specific hours only, combine with an hour range: `*/30 9-17 * * *` runs every 30 minutes between 9 AM and 5 PM.

Can I use both day-of-month and day-of-week together?

Yes, but they use OR logic. `0 0 15 * 3` runs at midnight on the 15th of every month AND at midnight on every Wednesday. It does NOT require the 15th to be a Wednesday. To schedule a job for only the 15th when it falls on a Wednesday, you would need to add a condition check inside the script itself.

Why does my cron job not run at the expected time?

Common causes include: (1) timezone mismatch — the cron daemon uses the system's local time, not UTC unless explicitly configured; (2) incorrect field ordering — the five fields are minute, hour, day, month, weekday; (3) PATH issues — cron uses a minimal environment; (4) the cron daemon is not running — check with `systemctl status cron` or `pgrep cron`; (5) permission errors — the script may not be executable or the user may lack permissions.

How do I run a job every Monday at 3 PM?

Use `0 15 * * 1` (minute 0, hour 15, any day, any month, Monday=1). Alternatively, `0 15 * * MON` works in some cron implementations that accept three-letter weekday abbreviations, though this parser supports numeric values only.

What is the difference between cron, anacron, and systemd timers?

Cron runs jobs at specific wall-clock times and assumes the system is always running. Anacron is designed for systems that may not run continuously — it catches up on missed jobs after the system starts. Systemd timers are more modern replacements that offer finer control, calendar-based expressions, resource management, and integrated logging. Each has appropriate use cases.

How do I validate a cron expression programmatically?

In JavaScript/TypeScript, you can validate a cron expression by splitting it into five fields and checking each for valid values and syntax. Libraries like `cron-parser` (npm) provide robust parsing. For a quick check, this parser validates the expression as you type and displays errors for malformed fields.

Does daylight saving time affect cron schedules?

Yes, if your system uses local time. When clocks jump forward (spring), jobs between 2-3 AM are skipped. When clocks fall back (fall), jobs between 2-3 AM may run twice. Systems using UTC as the hardware clock avoid this issue entirely. Most production servers should use UTC for cron scheduling.

What does a */10 in the weekday field mean?

It is rarely used, but */10 in the weekday field (0-7) would match Sunday (0) only, since stepping by 10 from 0 exceeds the maximum value of 7 after a single step. More commonly, step values are applied to the minute or hour field where the range is larger.

How are multiple values in a field evaluated?

Comma-separated values act as a logical OR. `15,45 0,12 * * *` means “at minute 15 and 45 of hours 0 and 12” — the job runs at 00:15, 00:45, 12:15, and 12:45. Each comma-separated part can itself be a range or step expression.

Can this parser handle @reboot or other shorthand expressions?

No. This parser implements the standard five-field numeric format. Shorthand strings like @reboot, @yearly, @hourly are non-standard extensions and are not supported. Convert shorthand to five-field form: @yearly = 0 0 1 1 *, @monthly = 0 0 1 * *, @weekly = 0 0 * * 0, @daily = 0 0 * * *, @hourly = 0 * * * *.

References and Sources

1. [1]The Open Group Base Specifications — cron
2. [2]GNU mcron — Mellor's cron daemon documentation
3. [3]FreeBSD System Manager's Manual — cron(8)
4. [4]Quartz Scheduler — Cron Expression Tutorial
5. [5]AWS CloudWatch Events — Cron Expressions
6. [6]systemd.timer — systemd timer unit documentation
7. [7]Linux Documentation Project — Cron How-To