Five terse fields separated by spaces can schedule a task to run every minute, once a year, or only on the second Tuesday of the month — but reading a cron expression cold is genuinely hard. This tool parses one and explains, in plain language, exactly when it will run.
A scheduling syntax nearly as old as Unix itself
Cron traces back to Bell Labs' Unix systems in the early 1970s, credited to developer Brian Kernighan among others, designed to let system administrators schedule recurring jobs (backups, log rotation, maintenance scripts) without manually triggering them — the name "cron" derives from the Greek "chronos," meaning time. Its five-field syntax (minute, hour, day of month, month, day of week) has remained essentially unchanged for over five decades, adopted far beyond its original Unix context into modern tools like Kubernetes CronJobs, CI/CD pipeline schedulers, and countless SaaS platforms' "run this task periodically" features — a remarkable case of a 1970s command-line convention becoming the de facto standard for scheduling across the entire software industry.
How the parser reads an expression
Each of the five fields accepts a number, a wildcard (*, meaning "every"), a range (1-5), a list (1,3,5), or a step value (*/15, meaning "every 15 units") — the tool evaluates all five fields together to determine the exact set of minutes, hours and days a job will run, then translates that combination into a human-readable description and, typically, a list of the next several upcoming run times.
Where reading cron expressions correctly actually matters
- Verifying a scheduled job before deploying it — confirming a cron expression does what you intend before it goes live is much cheaper than discovering, after the fact, that a job is running every minute instead of once a day.
- Debugging an unexpected job execution pattern — when a scheduled task runs at the wrong time or unexpected frequency, decoding its exact cron expression is usually the fastest way to spot the specific field that's misconfigured.
- Reviewing infrastructure-as-code and CI/CD configuration — Kubernetes CronJobs, GitHub Actions scheduled workflows, and various CI/CD pipeline configs all use cron syntax, and reviewing a pull request that changes one benefits from a clear, plain-language translation.
- Learning cron syntax itself — seeing immediate feedback on what a specific expression actually means is a far more effective way to internalize cron's terse field-based syntax than memorizing the format abstractly.
Frequently asked questions
What does an asterisk mean in a cron field? It means "every possible value" for that field — an asterisk in the minute field means "every minute," while one in the day-of-month field means "every day," and a cron expression of five asterisks (* * * * *) means "run every single minute."
Why do some cron implementations support extra fields, like seconds? Standard Unix cron only supports the five fields described here, but several modern implementations (including Spring Framework's scheduler and some cloud platforms) extend the syntax with an optional sixth "seconds" field for finer-grained scheduling — worth confirming which convention your specific platform uses, since a six-field expression will parse incorrectly against strict five-field cron logic.
What's a common mistake people make with day-of-month and day-of-week together? When both fields are set to something other than a wildcard, most cron implementations treat them as an "OR" condition (run if either matches) rather than an "AND," a genuinely counterintuitive behavior that catches out even experienced engineers scheduling something like "the 1st of the month, if it's also a Monday."
Further reading
Wikipedia — Cron — History of the cron utility and its five-field scheduling syntax.
Kubernetes — CronJob — A modern platform that adopted the same decades-old cron syntax for scheduled workloads.