Cron Expression Parser

Decodes cron strings into plain English, shows a per-field breakdown, and computes the next run times so you know exactly when a job will fire.

5-field standard, 6-field with seconds, 7-field with year. Special chars *, ,, -, /, ?, L, W, # and aliases @yearly, @monthly, @weekly, @daily, @hourly.

Yes — all parsing and next-run math happens client-side. No cron expressions are sent to a server.

Yes, the Cron Expression Parser is 100% free with no registration, no hidden fees, and no usage limits. All processing happens locally in your browser, ensuring complete privacy.

Absolutely. The Cron Expression Parser processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the Cron Expression Parser is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the Cron Expression Parser in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

The Cron Expression Parser supports a wide range of popular formats and languages. Check the tool interface for the full list of supported options.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

A standard cron expression has five space-separated fields, read left to right: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC), and day of week (0-6, where 0 and 7 both mean Sunday, or SUN-SAT). So "30 8 1 * 1" reads as minute 30, hour 8, on day-of-month 1, any month, and Monday. An asterisk means "every value" for that field. Some schedulers add a leading seconds field for six fields, or a trailing year field for seven. The hard part is that the raw tokens never spell out what they match, which is exactly why misreads happen. Paste any expression into the parser and it labels each field, lists the concrete values it matches, and writes the whole schedule as a plain-English sentence so you can confirm it at a glance.

It runs on both the 13th of every month AND every Friday, not only when the two coincide. This surprises many engineers. In standard Vixie cron, when both the day-of-month and day-of-week fields are restricted (neither is a bare asterisk), the scheduler treats them as an OR: the job fires whenever either field matches. So "0 0 13 * 5" triggers far more often than "Friday the 13th." To actually target Friday the 13th you need a different approach, since plain cron cannot express that AND condition directly. The parser follows the same OR rule your server uses, so the previewed timestamps reflect real behavior. Enter the expression and read the next ten run dates to see immediately whether your schedule fires more often than you intended.

The most common cause is a timezone mismatch. Most servers and container schedulers run cron in UTC, while you reason about the schedule in your local time. An expression like "0 9 * * *" means 9 AM in whatever timezone the scheduler uses, so if your machine is on UTC but you live several hours away, the job fires at a local hour you did not expect. Daylight saving transitions add further drift around spring-forward and fall-back dates. The fix is to always confirm which timezone the scheduler interprets the expression in, then convert deliberately. This parser lets you toggle the next and previous run times between your local timezone and UTC, so you can line the two up side by side and catch an off-by-hours error before deploying.

They mean very different things. A step value like "*/15" in the minute field means "every 15 minutes" — it matches minutes 0, 15, 30, and 45, so the job runs four times an hour. A plain "15" matches only minute 15, so the job runs once an hour, at quarter past. The slash introduces a step interval, and it can be combined with a range too: "0-30/10" matches 0, 10, 20, and 30. Mixing these up is an easy way to make a job fire four times more or less often than you planned. The parser expands any step expression into the exact list of values it matches and shows a frequency summary like "Runs 96 times per day," so you can verify the cadence instantly rather than counting in your head.

These are extended characters used by Quartz-style schedulers for calendar rules that plain ranges cannot express. "L" means "last": in the day-of-month field it matches the last day of the month, and as "5L" in the day-of-week field it means the last Friday. "W" finds the nearest weekday to a given day, so "15W" runs on the weekday closest to the 15th, skipping weekends. "#" picks the Nth weekday of the month, so "2#1" means the first Monday and "6#3" the third Friday. There is also "?", a no-specific-value placeholder used in the day fields when you have set the other. These rules are powerful but easy to misread. Paste an expression using any of them and the parser decodes each one in plain English and previews the real dates it produces.