Cron Expression Parser

A backup scheduled for the wrong hour may compete with production traffic, while a cleanup job that never matches can fail silently for weeks. Five-field cron expressions control those calendar decisions in a compact line. Each minute, a cron service compares the current minute, hour, date, month, and weekday with the allowed values in the schedule; when the fields match, the attached command can run.

The small syntax hides several important distinctions. An asterisk selects the full range of a field, a comma joins selections, a hyphen creates an inclusive range, and a slash steps through values inside a field. A step such as */15 in the minute position selects 0, 15, 30, and 45; it does not measure 15 elapsed minutes from the previous run across every circumstance.

The two day fields are the most common source of surprise. In the Unix behavior modeled here, restricting both day of month and day of week creates an OR rule. 0 4 1 * MON runs at 04:00 on every Monday and on the first day of every month, not only when the first is a Monday.

Timezone and dialect matter as much as syntax. The same five fields can produce different real instants on machines in different zones, and daylight-saving transitions can skip or repeat local clock times. Quartz, Jenkins, Kubernetes, systemd timers, and vendor schedulers may add seconds, years, hashed values, last-day rules, or different day semantics. A valid preview for one subset is not proof that another scheduler interprets the expression the same way.

Cron also schedules by calendar fields rather than by job completion. If a task runs longer than its interval, another instance may start unless the command or surrounding system prevents overlap. Preview the calendar matches, then verify timezone, command environment, locking, permissions, and logs on the target host.

How to Use This Tool:

Parse the schedule fields first, then compare the preview with the timezone and cron dialect used by the target system.

1. Enter a five-field Cron expression or choose a preset. Include only the schedule, not the command from a full crontab line.
2. Choose Browser local time or UTC for the preview basis.
3. Set Preview start when a repeatable review is needed. Otherwise the preview begins from the next whole minute after the page was opened.
4. Choose 3 to 24 Preview runs and optionally record the Deployment timezone note. The note documents context but does not change the calculation.
5. Review the expanded fields and upcoming timestamps. Fix a field-count, range, step, or unsupported-dialect error before using the schedule.
6. Check the day-matching, daylight-saving, step, macro, and timezone notes before installing the expression on the target scheduler.

Interpreting Results:

The expanded field values are the clearest syntax check. Confirm that every minute, hour, date, month, and weekday you intended appears, and that no extra value was introduced by a list, range, or step.

Upcoming timestamps prove how this parser applies its supported rules from the selected start and time basis. They do not query the target daemon. Before deployment, match the preview basis to the server or configured cron timezone and test a harmless command that leaves a timestamp in a log.

@reboot is valid but has no clock-based preview because it depends on daemon startup. A valid schedule with no match inside the five-year scan window needs review for an impossible calendar combination or an overly narrow filter.

Technical Details:

The parser expands each field into a sorted set of allowed integer values, then scans forward one minute at a time. Minute, hour, and month must match. The day decision uses OR when both day fields are restricted; otherwise both expanded day sets must accept the date because the unrestricted field contains every valid value.

Rule Core

Expressions may contain at most 160 characters and must have exactly five fields unless they are a supported macro. Quartz or Jenkins tokens containing ?, L, W, H, or # are rejected. Randomized tilde syntax is also rejected because it has no deterministic preview.

Preview mechanism

The explicit preview start must be a real minute in the selected local or UTC basis. Matching begins one minute after that start, so a schedule that matches the start itself appears at its next occurrence. The scan stops after the requested 3 to 24 matches or after five years of minute candidates, whichever comes first.

Each interval is the elapsed number of minutes since the prior row, with the first interval measured from the preview start. UTC preview uses UTC calendar fields. Browser-local preview uses the browser's local calendar and follows its daylight-saving transitions, where a wall-clock minute can be skipped or repeated.

A Rule Core is used instead of a Formula Core because the governing mechanism is set expansion plus ordered calendar predicates, not a single arithmetic equation. The timestamps are deterministic only when the expression, start minute, preview basis, and environment timezone rules remain fixed.

Accuracy Notes:

This is a Unix five-field subset with selected common macros. It does not execute commands or inspect a server's cron configuration.

• Local preview follows the browser timezone, which may differ from the target host or container.
• Scheduler extensions and day-field behavior can vary by implementation; confirm the target manual.
• @reboot depends on cron daemon startup and cannot be predicted from clock time.
• A schedule preview does not test command paths, environment variables, permissions, locking, missed-run behavior, or output delivery.

Worked Examples:

References:

• crontab utility and input format, The Open Group, POSIX.1-2017.
• crontab(5), Debian Manpages.
• How to create a cron job in Linux, Simplified Guide.