/en/tool/cron-parser/ works Calculated in the browser
Paste a schedule expression — the tool will explain in Russian when the job runs and show the next runs in two columns: based on the server clock in the selected time zone and your clock. It supports five Unix fields, six or seven Quartz and Spring fields, plus L, W, and the # sign. You do not have to write the expression by hand: there is a builder and about 50 ready-made schedules, along with ready-to-use snippets for crontab, Kubernetes, GitHub Actions, systemd, and AWS EventBridge. Everything is calculated in the browser.
Parsing happens on your device: neither the expression nor the commands are sent anywhere.
What each field contains, how it expands, and how many values it produces.
| Field | Entered | Values | Count |
|---|
Time conversion
The number in each cell shows how many times the task runs that day according to the server's clock. An empty cell means there are no runs that day.
| Mon | Tue | Wed | Thu | Fri | Sat | Sun | Per week |
|---|
Choose a ready-made schedule or build your own with the mouse. The expression is sent to the field above immediately and parsed by the same code, so you don't have to construct it mentally.
More than once an hour
Hourly
Daily
Weekly
Monthly and less often
—
The same schedule for places where it is usually transferred manually. Conversion to UTC is already done where a time zone cannot be set.
Inserted into a crontab line, a Kubernetes container, a GitHub Actions step, and a systemd unit. It does not affect schedule parsing.
Paste the file as is—with comments, variables, and commands. Each line will get a plain-English description and its next run time, and lines that run simultaneously will be marked.
Lines starting with # and assignments like PATH=… are skipped. Aliases such as @daily are parsed the same way as regular entries.
Empty
| Line | Schedule | Command | Meaning | Next run |
|---|
First, set the server time zone—the one where cron runs. Everything else is calculated in that zone, while your local time appears in a second column, so you no longer have to keep the difference in mind.
Paste the schedule line without the command. If you would rather not write the line yourself, choose a ready-made one from the “Builder” section or assemble it field by field using the switches.
Check the plain-English description and the list of runs. The list is the most important part: it shows not what you intended, but what the expression actually produces.
Review the field breakdown. It shows how each entry was expanded and how many values remain in it. Errors in a step or range are visible there.
Check the month view. A gap such as “no run on the 31st in April” appears as a cell without a number before you even finish reading the warnings.
If the time zone observes daylight saving time, read the separate block. It states which run will disappear in spring and which hour will repeat in fall.
Take the generated files in pieces: a crontab line, a CronJob for Kubernetes, a workflow for GitHub Actions (the time is already converted to UTC there), a systemd timer, and an AWS EventBridge expression. Download everything together as one file.
Paste an entire crontab into the last section. It will parse every line and show which jobs start in the same minute.
minute hour day of the month month day of the week
Fields are joined with “and”: all conditions must match at once. There is one exception: the day of the month and the day of the week. In ordinary cron and Spring, when both are set, they are joined with “or,” and the job runs on either type of day. Quartz does not work this way and requires one of the two fields to be a question mark.
The input data is the same as the default field values: you can calculate it mentally and confirm that the tool is telling the truth.
Four runs per hour: 60 ÷ 15 = 4.
There are ten hours in the range from 9 through 18 inclusive.
Runs per day: 4 × 10 = 40 runs.
There are about 260 weekdays in a 12-month window: 52 weeks plus a remainder, with 5 weekdays in each week.
If you are in Yekaterinburg, the same runs appear in the second column from 11 a.m. to 8 p.m.—two hours later because the server runs on Moscow time.
In GitHub Actions, you would have to write the same schedule as 6-15 instead of 9-18 because its time is always UTC. The converted version is ready in the configs section.
That gives 40 runs per day and about 10,400 per year. Plain English: every 15 minutes from 9 a.m. to 6 p.m. on weekdays.
Ask the server itself: the timedatectl command shows the Time zone line. If it is missing, check where /etc/localtime points or run date. Enter the resulting name, such as Europe/Moscow, in the field. The suggestion list is built from the time zones your browser knows. If the server runs on UTC—as most cloud machines and all containers do by default—click the UTC button.
It depends on the direction of the change. In spring, an hour disappears: a schedule set for that nonexistent time will not run at all that day. In fall, an hour repeats, so the same clock time occurs twice—ordinary cron runs the job once, on the first occurrence. The tool looks for transitions in the selected time zone over the next 12 months and states on a separate line which date and run are affected in each case. In zones without daylight saving time, including Russian zones, this block stays empty—and that is the correct answer.
Yes, in Quartz and Spring modes. L is the last day of the month, L-3 is three days before the last day, LW is the last business day, 15W is the business day closest to the 15th, 5#3 is the third Thursday, and 5L is the last Thursday. In Unix mode, these symbols are still treated as errors because ordinary cron really does not understand them. Switch the dialect at the top of the panel.
By numbering the days of the week. In Quartz, Sunday is 1 and Monday is 2; in Spring and ordinary cron, Sunday is 0. The same string “0 0 9 ? * 2” means Tuesday in Spring and Monday in Quartz. Quartz also requires a question mark in one of the two day fields and supports a seventh field for the year. If the dialect is set to “Detect,” six fields are interpreted as Spring, as stated in a separate note.
This is an “or” rule. The string “0 0 13 * 5” means not “Friday the 13th,” but “the 13th of every month and every Friday as well.” To require an exact match, put the weekday restriction inside the command itself, not in the schedule. This string simply does not exist in Quartz: there, one of the fields must be a question mark.
Because schedules in GitHub Actions are always evaluated in UTC; you cannot set a time zone there. The tool shifts the hours by the difference from the selected time zone and writes the resulting string into a ready-to-use workflow. The difference is based on today: if your time zone observes daylight saving time, the job will run an hour earlier or later for half the year. This is a limitation of GitHub itself, not of the conversion.
These are recognized: @hourly, @daily, @midnight, @weekly, @monthly, @yearly, and @annually. They are simply shortcuts for common schedules, and the notes show what each one expands to. The @reboot alias is also recognized, but it cannot be predicted—it is tied to a machine reboot, not to the calendar.
Nothing. Parsing, run lookup, daylight saving time transition lookup, and config generation all happen in your browser on your device. The pasted crontab, including commands and paths, is not sent anywhere either. The expression and selected time zone are stored in the page URL after the hash. The browser does not send that part of the URL to the server, but you can share the link and your colleague will see the same analysis.
Creates passwords of the required length and assesses how difficult they are to crack.
Open