Our cron expression parser translates cron schedules into plain English and calculates upcoming execution times. Paste any cron expression and instantly see what it means, when it will run next, and whether the syntax is valid. Supports standard 5-field crontab format (minute, hour, day, month, weekday), extended 6-field format with seconds, and common presets like @daily, @hourly, @weekly. All processing happens in your browser.
Type or paste a cron expression (5 or 6 fields). Use presets for common schedules.
See the human-readable translation of what your cron expression does.
View the next 10 execution times to verify your schedule is correct.
Use the interactive builder to create a new cron expression from scratch.
A cron expression is a schedule definition using 5 space-separated fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0=Sunday). Each field can use wildcards (*), ranges (1-5), lists (1,3,5), and step values (*/5). Some systems support a 6th field (seconds) at the beginning.
┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-6, Sun=0)
* * * * *
*/5 * * * * means every 5 minutes — the / is the step operator
0 0 * * 0 runs at midnight every Sunday (day 0 = Sunday in most systems)
Use @daily, @hourly, @weekly, @monthly as shortcuts for common schedules
Day of week: 0=Sun, 1=Mon, 2=Tue, 3=Wed, 4=Thu, 5=Fri, 6=Sat
Both day-of-month and day-of-week can't be specific simultaneously in standard cron
Month names (JAN-DEC) and day names (SUN-SAT) work in many cron implementations
Always test cron expressions before deploying — off-by-one errors are common
Our free cron expression parser translates cron schedules into human-readable text and shows upcoming execution times. Validate cron syntax, understand each field, and verify your schedules before deploying. Supports standard 5-field and extended 6-field cron formats.
Paste any cron expression and instantly see what it means in plain English. Our parser breaks down each field (minute, hour, day, month, weekday) and explains the schedule.
Supports:
See exactly when your cron job will execute next. Our calculator shows the next 10 run times with dates and timestamps, so you can verify your schedule is correct before deploying to production.
Never deploy a wrong cron schedule again.
A cron expression works by matching the current time against a pattern of five space-separated fields:
The cron daemon (crond) wakes every minute and runs any job whose fields all match the current clock, as described in the POSIX crontab specification and the Linux crontab(5) manual page. Each field accepts a wildcard (*) for "any value," plus ranges, lists, and step operators.
Vixie cron, the widely deployed implementation on most Linux distributions, follows this behavior. Understanding that cron evaluates minute-by-minute explains why cron cannot natively schedule tasks at sub-minute intervals without a seconds field.
The five cron fields, read left to right, are:
This ordering is defined by the POSIX standard (IEEE Std 1003.1) and documented in the crontab(5) man page maintained at man7.org. Month and weekday fields also accept three-letter abbreviations such as JAN through DEC and SUN through SAT in most implementations.
A key POSIX rule: when both day-of-month and day-of-week are restricted (neither is *), cron runs the job if either field matches, not both. This OR behavior surprises many developers and causes unexpected extra executions.
Cron step, range, and list operators let you express complex schedules compactly.
These operators are documented in the crontab(5) manual and the Vixie cron source. For example, */5 9-17 * * 1-5 fires every five minutes between 9 AM and 5 PM on weekdays.
Combining operators keeps crontab lines readable while covering intricate recurring windows.
Cron special strings are named shortcuts that replace the five-field syntax for common schedules.
These aliases originate from Vixie cron and are documented in the crontab(5) manual page on man7.org. A special case, @reboot, runs a job once when the system starts rather than on a clock schedule.
Note that not every cron implementation supports these strings; POSIX cron does not require them, so verify support before relying on them in portable scripts.
Standard Unix cron does not support seconds; its smallest resolution is one minute because crond evaluates the schedule once per minute, per the crontab(5) specification.
To schedule tasks with second-level precision, developers use extended cron dialects that add a leading sixth field. The Quartz Scheduler and Spring's @Scheduled cron syntax both place seconds first, giving second minute hour day-of-month month day-of-week. AWS EventBridge (formerly CloudWatch Events) uses a six-field cron with a year field instead.
Because these formats differ, a six-field expression written for Quartz will not run correctly in vanilla crontab. Always confirm which engine parses your expression, since field count and offsets vary between systems.
Time zones affect cron jobs because most cron daemons evaluate schedules against the system's local time, not UTC. When the server observes Daylight Saving Time transitions, jobs scheduled during the skipped or repeated hour may be missed or run twice; the crontab(5) manual and IANA Time Zone Database documentation both describe these edge cases.
To avoid ambiguity, many teams set the server or the crontab CRON_TZ variable to UTC, following guidance similar to that in ISO 8601 for unambiguous timekeeping. Cloud schedulers such as Google Cloud Scheduler and AWS EventBridge let you specify a time zone explicitly.
When precise timing matters, always document whether an expression is UTC or local.
To test a cron expression safely, validate its syntax and preview upcoming run times before adding it to a live crontab. This parser checks field ranges and operators, then lists the next execution times so you can confirm the cadence matches your intent.
On a server, run crontab -l to review existing jobs and crontab -e to edit them, as described in the crontab(1) and crontab(5) manual pages. Redirect job output to a log file (for example, appending >> /var/log/myjob.log 2>&1) so failures are visible.
Testing first prevents costly off-by-one errors, such as confusing minute and hour, that only surface once a schedule fires in production.
The most common cron mistake is misreading field order and swapping minute with hour, so 0 9 * * * (9 AM) becomes 9 0 * * * (00:09).
Cron expressions are used throughout DevOps and CI/CD to trigger recurring automation without manual intervention. GitHub Actions schedules workflows with a standard five-field cron in the on.schedule.cron key, and GitLab CI pipeline schedules use the same syntax.
Kubernetes CronJobs, defined in the batch/v1 API, run containerized tasks on a cron schedule, as documented in the official Kubernetes docs. Cloud platforms including AWS EventBridge, Google Cloud Scheduler, and Azure Logic Apps expose cron-style scheduling for serverless jobs.
Common uses include:
Because each platform may use a slightly different dialect, always validate your expression against the target system's parser.
Data sourced from trusted institutions
All formulas verified against official standards.