Cron Parser

A cron parser reads a cron expression, checks its field syntax and allowed ranges, explains the schedule in plain English, and can calculate upcoming execution times. It helps you inspect a schedule before placing it in crontab, a CI workflow, a container scheduler, or a cloud job configuration.

Paste an expression such as `*/15 9-17 * * 1-5`, choose the dialect and timezone, and select Parse expression. The page shows a normalized expression, a human-readable summary, a field-by-field table, warnings, and the next scheduled times calculated in the browser.

Standard Unix or POSIX cron uses five fields in this order: minute, hour, day of month, month, and day of week. The usual ranges are minute 0–59, hour 0–23, day of month 1–31, month 1–12, and day of week 0–7, where Sunday may be represented by 0 or 7 depending on the implementation.

The expression `* * * * *` means every minute in standard five-field cron. Each asterisk allows every value in its field, so the schedule has no restriction on minute, hour, calendar day, month, or weekday.

`*/5 * * * *` means every five minutes in standard Unix-style cron. The step begins at minute 0 and includes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 of every hour.

A comma creates a list such as `1,3,5`; a hyphen creates an inclusive range such as `9-17`; and a slash creates a step such as `*/15` or `1-30/5`. A field can combine lists, ranges, and steps when the target scheduler supports that syntax.

Yes. The parser accepts common names such as `JAN` through `DEC` for months and `SUN` through `SAT` for weekdays in the supported modes. It normalizes names for explanation while keeping the original expression visible. Always confirm the accepted names in the scheduler where the job will run.

Yes. Common recurring shortcuts such as `@yearly`, `@monthly`, `@weekly`, `@daily`, `@midnight`, and `@hourly` are expanded locally and shown in the schedule note. `@reboot` is treated as an event trigger rather than a calendar recurrence, so the page does not invent a next timestamp for it.

Unix or POSIX cron normally has five fields beginning with minute. Quartz commonly adds a seconds field and may add a year field, producing six- or seven-field expressions, and it uses `?` for no specific day-of-month or day-of-week value. These dialects are not interchangeable; select the matching mode before interpreting an expression.

Yes. Seconds-prefix mode expects six fields in this order: second, minute, hour, day of month, month, and day of week. Quartz mode also accepts six fields, but its day-field conventions can differ, so use the mode that matches the scheduler or library that will execute the job.

Yes. Quartz mode accepts seven fields: second, minute, hour, day of month, month, day of week, and year. The year preview is limited to a practical browser range and the result should still be checked against the exact Quartz implementation and timezone configuration used by the application.

The page exposes an explicit DOM/DOW policy. Standard POSIX cron commonly treats two restricted day fields as an OR condition, while some Quartz-style expressions use `?` to mark one day field as unspecified and effectively require the other. When both fields are restricted, the page displays a warning so you can confirm the intended scheduler semantics.

Yes. Choose browser local time, UTC, or one of the provided named timezones and select 5, 10, or 20 upcoming runs. The preview displays the selected-zone time, the UTC equivalent, and a relative label. The calculation uses the current browser clock and does not call a server.

The preview formats dates using the selected browser timezone, but daylight-saving behavior is ultimately controlled by the scheduler and its timezone database. A local preview is useful for catching many mistakes, not a guarantee of how every platform handles skipped or repeated wall-clock times during DST transitions.

Different tools may assume different field counts, timezones, Sunday numbering, day-of-month/day-of-week semantics, daylight-saving rules, seconds behavior, or special operators. Compare the dialect, timezone, current reference time, and scheduler documentation instead of assuming that every cron expression has one universal interpretation.

The page reports missing or extra fields, invalid numeric or named values, out-of-range values, malformed lists, invalid ranges, invalid steps, unsupported shortcuts, and unsupported Quartz wildcard usage. Warnings also call out restricted day fields and dialect boundaries instead of silently accepting ambiguous input.

The tool is designed as a free browser utility with no account required. Parsing, validation, schedule explanation, next-run calculation, copy, and report generation run locally. The expression is not uploaded or persisted by the page, although clipboard permissions and access to a shared device remain outside the tool.

Yes. Copy summary places the current expression, dialect, timezone, schedule explanation, field breakdown, warnings, and upcoming runs on the clipboard. Download report saves the same information as a local plain-text file for documentation, tickets, or deployment review.

No. A parser verifies an expression against its implemented rules and previews dates; it does not prove that the job command exists, permissions are correct, a worker is running, a cloud service accepts the syntax, or the scheduler will survive outages. Validate the expression in the target platform and monitor the actual job.

Confirm the scheduler dialect and field count, timezone, DST policy, day-of-month/day-of-week behavior, named-value support, command environment, permissions, working directory, output and error handling, overlap behavior, retries, and the intended next few run times. Test both a known-valid and known-invalid expression before deployment.