An online cron parser is a browser-based validator that accepts a classic five-field crontab expression, confirms each field against its permitted range, normalizes spacing, and lists the next five matching run times in both local and UTC clock formats. A five-field cron expression contains exactly minute, hour, day of month, month, and day of week, each separated by a space, and a parser enforces that structure before it attempts any calculation. The value of an online tool is fast feedback: paste a schedule, see whether each field selects what you intended, and walk away knowing when the underlying scheduler will next fire the job. Cron Parser does exactly that and follows the documented Cronie-style rules, including the often-misunderstood OR behavior when both day fields are restricted. It runs locally in the browser, does not execute or save expressions, and produces a normalized form along with a plain-English summary of every field.
What a Cron Parser Actually Does
Cron Parser accepts a string of exactly five whitespace-separated fields, parses each one against the conventional numeric range, and reports both a normalized form of the input and a plain-language summary of what each field selects. It then enumerates future minutes, expressed in UTC, until it finds five matches or stops after a five-year safety bound. The two outputs you compare in practice are the browser's local clock and the matching UTC timestamps, which makes it easy to confirm the result against a server in another time zone.
Because the engine iterates over real UTC instants, daylight-saving shifts never produce a skipped or duplicated run inside the calculation itself; the parser instead hands you a deterministic list and trusts you to verify the configured zone of the scheduler that will actually execute the job. Calendar validity is delegated to the JavaScript Date object, so day 31 naturally skips months without a thirty-first day and February rules respect leap years. The parser does not call any server, run the command, or persist the expression anywhere. Everything happens in your browser tab, and the input you type is treated as text only.
The Classic Five-Field Format and Its Ranges
Traditional crontab syntax uses five fields in this fixed order: minute, hour, day of month, month, and day of week. Anything else, including a leading seconds field or a trailing year field, is considered a non-classic dialect and is rejected before any field is expanded. Each field has a documented numeric range, and the table below summarizes the exact boundaries the parser checks against. Two weekday values, 0 and 7, are both treated as Sunday so that 0 0 * * 7 and 0 0 * * 0 behave identically.
The parser will not silently coerce other numbers, so a value such as 13 in the month field or 60 in the minute field produces a focused rejection message that points at the offending field. Empty list items, extra command text after the fifth field, and any count other than exactly five fields are likewise rejected. These limits exist because the parser deliberately targets the portable numeric core rather than every cron dialect.
| Field | Order | Valid values | Notes |
|---|---|---|---|
| Minute | 1 | 0 to 59 | Whole minutes only, no fractions |
| Hour | 2 | 0 to 23 | 24-hour clock |
| Day of month | 3 | 1 to 31 | Months without that day are skipped |
| Month | 4 | 1 to 12 | Names like JAN are not accepted |
| Day of week | 5 | 0 to 7 | 0 and 7 both mean Sunday |
Syntax Accepted: Wildcards, Lists, Ranges, and Steps
Inside any single field you can mix four kinds of tokens. An asterisk * means every value allowed in the field. A comma-separated list combines individual values, with optional ranges between values, such as 0,15,30,45 or 8-12,14,18-20. An inclusive numeric range such as 10-50 selects every integer from the start to the end. A step expression appends /N to either an asterisk or a range, which selects every Nth value beginning at the field minimum or at the start of the range.
For example, */15 in the minute field expands to 0, 15, 30, and 45, because it counts every fifteenth value starting at the field minimum of 0 and stops at the field maximum of 59. A range with a step such as 10-50/20 evaluates as 10, 30, and 50; the step begins at the range start and never exceeds the range end. These are documented expansions of the same syntax, not per-instance calculator outputs. Descending ranges, zero or negative steps, empty list items, and values outside the field range are rejected with a focused error so you can fix the offending field immediately.
| Token | Meaning | Example | Result |
|---|---|---|---|
| Number | One value | 5 | 5 |
| * | All values | * | Every allowed value |
| List | Multiple values | 0,15,30,45 | 0, 15, 30, 45 |
| Range | Inclusive range | 8-12 | 8, 9, 10, 11, 12 |
| Step | Every Nth value | */15 | Every 15th starting at 0 |
How to Validate an Expression and Read the Next Five Runs
Open the tool, paste the expression into the input, and review the three outputs the parser produces for it: a normalized string, a per-field summary, and a table of upcoming runs. The steps below walk through the workflow you should follow every time you verify a schedule before deploying it.
- Enter exactly five fields in the order minute, hour, day of month, month, and day of week, separated by single spaces. Extra spaces are normalized away; anything other than five fields is rejected before any field is expanded.
- Build each field from numeric values, * wildcards, comma lists, inclusive ranges, or positive steps such as */15. Avoid names like JAN or MON, since the classic parser does not accept named months or weekdays.
- Read the normalized expression to confirm spacing and weekday handling, then read the field summary to confirm each field selects the values you intended. The summary is the fastest way to catch a field placed in the wrong position.
- Inspect the next five matching run times in both your browser's local time and as ISO UTC timestamps. Local and UTC outputs differ by your offset and by any daylight-saving shift in effect at each instant.
- Cross-check the expression and time zone against the documentation for the scheduler that will actually execute the job, whether that is Cronie, Vixie cron, systemd timers, or a cloud scheduler. The parser output is verification, not deployment.
A helpful way to read the upcoming-runs table is to sort the output by your local clock and verify that the first row lines up with what you expected from the expression, then glance at the UTC column to confirm the absolute instants match a server-side reference. If your browser shows 2026-03-08T14:00:00Z as the second row, a server configured for UTC should fire at exactly that instant.
Day-of-Month and Day-of-Week OR Semantics
Traditional cron behavior, documented in the Cronie crontab manual and reproduced in vendor guides such as the Oracle Linux cron guide, treats the two day fields as an OR when both are restricted. A rule selecting the 21st of the month and Monday, for example, fires on every Monday and also on the 21st, regardless of which weekday that date falls on. Cron Parser implements that OR behavior rather than requiring both fields to match. When one of the two day fields is a wildcard, the restricted field alone controls the match.
If you need AND semantics, restrict one field to a single value and use the wildcard in the other, or split the job into two scheduled entries with overlapping constraints. Misreading this rule is the most common cause of "the cron job ran on the wrong day" incidents, and the field-by-field summary in the parser output is built to surface that exact mistake before the job reaches production.
What the Parser Deliberately Rejects
The parser targets the portable numeric core of cron and intentionally ignores extensions that differ across products. It does not accept named months or weekdays such as JAN or MON, nicknames such as @daily or @reboot, seconds or year fields, Quartz question marks, last-day syntax, hashed schedules, random ranges, or vendor macros. A five-field expression dropped into a six- or seven-field scheduler can be silently reinterpreted or refused, so always read the destination product's documentation.
The same applies to day-field semantics: a cloud scheduler may treat day-of-month and day-of-week as an AND rather than the documented OR, which would change when the job runs even though the expression looks valid. Quartz, Kubernetes CronJobs, AWS EventBridge, and CI services each layer their own conventions on top of the classic format, and the parser output is a verification of the classic form only. Once the expression passes, the next decision is whether the destination supports that form at all.
Confirm Against Your Scheduler Before Deploying
The output of any parser is a verification aid, not a deployment guarantee. Before you ship a critical backup, billing, notification, or maintenance job, confirm three things against the scheduler that will execute it: the supported field count and extensions, the configured time zone and daylight-saving policy, and the documented day-field semantics. If those three line up with what the parser shows, the upcoming-runs table is the same schedule the scheduler will follow. If any of them differ, adjust the expression or pick a tool built for that dialect.
The companion Cron Expression Generator helps you build a classic five-field schedule from a readable description, which is a natural next step after you understand what each field selects. Treat the parser as the final read-through rather than the first step: build the expression, paste it into the parser, confirm the field summary, compare the next five runs against your expectations, then deploy.