Cron Expression Parser & Next-Run Preview

What is a cron job?

Cron is a background scheduler on Unix-like systems, and a cron job is one command plus the schedule that fires it. The daemon wakes every minute, examines every registered job, and runs those whose schedule matches the current time,¹ which is why cron expressions describe minutes rather than durations: the daemon does not count elapsed time, it matches wall-clock fields against the current minute. Nothing about a cron job is continuous; each firing is a fresh process spawned at a moment the expression selected. That model is simple, robust, and easy to reason about once you can read the five fields.

Each user's jobs live in their own crontab, a per-user file where every line pairs a schedule expression with the command to run. The schedule is the machine-readable half of the line and the command is what actually executes, so a crontab reads as a list of when-then pairs. You edit yours with crontab -e and list it with crontab -l,² and the daemon picks up the change without a restart.³ The command half can be anything the shell can run, from a one-line log cleanup to a full deployment script, and it runs with your account's permissions.⁴

This tool touches only the schedule half of the line. The parser validates the expression, translates it into plain English, and previews the runs it selects; the command half never enters this page, because a valid schedule here says nothing about whether the command will succeed when the daemon fires it. A job that is scheduled correctly but failing in production has a runtime problem, not a syntax problem, and the debugging section later in this article picks that side up. Preview the schedule here, then trust the daemon's own logs to tell you what happened when it fired.

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.⁶

Cron dialects across platforms

The five-field shape carries across modern scheduling platforms, from CI pipelines to container schedulers to serverless cron triggers, and each platform implements a dialect of it. Some prepend a seconds field to the familiar five; some number the days of the week differently; some reject month and day names; some enforce minimum intervals between runs; and one platform's wildcard can mean something another's does not. The core idea transfers, the details do not. Reading any platform's schedule field documentation is the only way to know which dialect you are writing.

This parser speaks the standard Unix dialect, verified against the five shared fields. When a platform's schedule misbehaves, read the platform's own schedule-field documentation first to learn its dialect, then confirm the five shared fields here; dialect-specific syntax is the platform's to document, and this page never claims to validate any platform's variant. Treating a platform's expression as standard Unix cron is the mistake the dialect map above exists to prevent. A next-runs preview is only as trustworthy as the dialect it was parsed in.

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.

When the schedule is right but the job still fails

Two runtime surprises account for most of the rest. First, cron jobs run with a minimal environment: the daemon sets only a handful of variables, such as the shell and home directory, rather than the full set an interactive shell provides, so a command that works in your terminal can fail from cron.² Second, anything the job prints is mailed to the crontab's owner rather than shown on any terminal,¹ so a job with no visible output is usually a job whose output nobody read. Redirecting each line's output and errors to a log file turns invisible failures into readable ones, which is the habit worth forming before you need it.

The debugging order matters. Read the daemon's log first to confirm the job fired at all; then capture the job's own output to see the real error; only then bring the expression back here to rule the schedule in or out. This parser validates the schedule and never the execution environment, so it is step one of a cron debugging loop, not the whole loop. Most jobs that "never ran" did run: the schedule fired, the command failed, and the evidence went to a mailbox nobody checks.