Cron Expression Parser & Next-Run Preview

The 5 cron fields

Every cron expression is a string of five fields separated by whitespace, and each field controls one dimension of the schedule. Reading them in order from left to right gives you minute, hour, day-of-month, month, and day-of-week, with an optional year field added by some implementations. Understanding what each field accepts and how the fields interact is the first step toward writing schedules that behave predictably in production.

The five fields are fixed in order, and changing the value of one field never shifts the meaning of the others. That independence is what makes cron composable: you can change the hour without touching the minute, or restrict the day-of-month without affecting the day-of-week. The trade-off is that a single misplaced character in any field can change the schedule in ways that are hard to spot without a preview, which is exactly the kind of mistake this tool is designed to catch.

Field order and accepted values

A standard Unix cron expression has five space-separated fields: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12), and day-of-week (0–7, where both 0 and 7 represent Sunday). Each field accepts a specific value, a wildcard * (every valid value), a range 1-5, a list 1,3,5, or a step */15. You can also use names in place of numbers for the month and day-of-week fields, such as mon,wed,fri or jan-mar.¹

Using steps and lists

Steps are the most compact way to express recurring intervals. */15 in the minute field runs at minutes 0, 15, 30, and 45, while 0-23/2 in the hour field runs every other hour. Lists let you pick several specific values at once, so 1,15 in the day-of-month field fires on the first and fifteenth. The tool translates each combination into plain English so you can verify intent before deploying.²

You can also combine a range with a step, as in 1-30/5, which fires on the 1st, 6th, 11th, 16th, 21st, and 26th of the month. Mixing these syntaxes across the five fields is what makes cron powerful but also easy to get wrong, which is exactly why a plain-English preview is worth checking before you save a new line.

Special @-shortcuts

Many cron implementations support @-prefixed shortcuts as readable aliases for common schedules. @hourly is equivalent to 0 * * * *; @daily to 0 0 * * *; @weekly to 0 0 * * 0; @monthly to 0 0 1 * *; and @yearly (or @annually) to 0 0 1 1 *. The special @reboot shortcut runs the job once when the system starts.¹

Timezones and your server

Cron expressions describe when a job should run, but the clock that evaluates them lives on the server that hosts the cron daemon. When your development machine, your production server, and your users span multiple timezones, the same expression can produce different wall-clock results depending on where it is executed. The tool surfaces this offset explicitly so you can reason about it rather than discover it after a missed run.

Server local time and UTC

Cron daemons use the local clock of the machine they run on, with no built-in timezone conversion of their own. If your server is in UTC and you schedule 0 9 * * * expecting a 9 AM job, it fires at 9 AM UTC rather than 9 AM in your local timezone. The tool previews run times using your browser's timezone, which may differ from your server's, and the timezone label shown in the preview makes that offset visible so you can reconcile the two clocks.⁴

Daylight saving transitions

Daylight saving transitions add another wrinkle for any time-based scheduler. When clocks spring forward, jobs that would have run during the skipped hour are typically executed immediately; when clocks fall back, the system avoids running the same job twice. The exact behaviour depends on your operating system and cron implementation. For jobs where exact local timing matters, consider using a timezone-aware scheduler such as systemd timers with OnCalendar, or a cron wrapper that handles DST transitions explicitly.⁵

Common schedule patterns

While cron syntax can express almost any schedule you can think of, a handful of patterns cover the vast majority of real-world jobs. Recognising these idioms makes it easier to read unfamiliar crontabs and gives you a head start when writing new ones. The examples below are the ones you will reach for most often, whether you are polling a queue, rotating logs, or running a monthly billing job.

Patterns for common intervals

A small set of expressions covers the majority of real-world scheduling needs. */5 * * * * runs every 5 minutes, which is a common polling interval for health checks and queue workers. 0 3 * * * runs nightly at 3 AM, a typical window for database backups and log rotation. 0 9 * * 1-5 runs at 9 AM on weekdays only, and 0 0 1 * * runs at midnight on the first of every month, which suits billing jobs and monthly reports.

Preview before deploying

When writing a new expression, enter it in the tool above to confirm the English description matches your intent, then check that the next 5 run times fall on the dates and hours you expect. Subtle syntax errors, such as a , where a - belongs inside a range, produce expressions that are still valid but schedule the wrong moments, and these mistakes are easy to miss without a preview. Always paste a new production cron line through the parser once before relying on it.

Avoiding common scheduling mistakes

Most cron surprises come not from obscure syntax features but from the way standard fields interact when you combine them in ways that feel intuitive. Day-of-month and day-of-week are the classic pair: specifying both produces a union rather than an intersection, and that behaviour catches out anyone expecting the job to fire only when both conditions line up. Once you understand these edge cases, you can lean on the tool's preview to confirm the schedule before it goes live.

How day-of-month and day-of-week interact

Day-of-month and day-of-week fields interact in a way that surprises many developers. In standard Unix cron, when you specify both a day-of-month value and a day-of-week value (neither is a wildcard asterisk), most implementations fire the job on days matching either condition, not only days that satisfy both. The expression 0 9 1 * 1 runs at 9 AM on the first of every month and at 9 AM every Monday, not only on Mondays that fall on the first. The plain-English description this tool generates makes the actual interpreted schedule visible before you deploy, so there are no surprises in production.²

Monthly jobs and the last-day gap

Monthly jobs that target a specific day face a reliability gap. The expression 0 0 31 * * silently skips February, April, June, September, and November, because those months have fewer than 31 days and the cron day-of-month field has no notion of the last day. Checking the Next 5 Runs preview for a monthly expression reveals exactly which calendar dates will fire and quickly exposes this kind of gap. When you need a job to run on the last calendar day of every month, the standard approach is a wrapper script that checks whether tomorrow is the first of the next month, rather than relying on a raw cron expression that cannot express the concept directly.