Cron Expression Generator & Explainer
Generate and explain cron expressions instantly. Build schedules visually with presets (minutely, hourly, daily, weekly, monthly) or type any cron string to get a plain-English explanation of exactly when it runs — with the next 5 execution times shown.
Generate and explain cron expressions instantly. Build schedules visually with presets (minutely, hourly, daily, weekly, monthly) or type any cron string to get a plain-English explanation of exactly when it runs — with the next 5 execution times shown.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
A cron expression is a string of five (or sometimes six) fields separated by spaces that defines a recurring schedule for a task. The name comes from the cron daemon — a Unix background process that reads a crontab file and executes scheduled commands. The five standard fields from left to right are: 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). A cron expression like 0 12 * * 1-5 means "at minute 0 of hour 12, every day of the month, every month, on days 1 through 5 of the week" — which resolves to "every weekday at noon."
Each field supports several special characters beyond plain numbers. The asterisk (*) means "every valid value for this field." A comma (,) separates multiple specific values — 1,15 in the day-of-month field means the 1st and 15th. A hyphen (-) defines a range — 1-5 in the day-of-week field means Monday through Friday. A forward slash (/) defines a step interval — */5 in the minute field means every 5 minutes (0, 5, 10, 15, 20... 55). Some cron implementations also support L for "last" (last day of month, last Friday), W for "nearest weekday," and # for "nth weekday of the month" (2#3 means the third Tuesday). These extended features are supported by Quartz scheduler (used in Java applications) but not by standard Unix cron.
A sixth field for seconds (0-59) appears in some implementations — Quartz scheduler uses a six-field format starting with seconds, AWS CloudWatch Events uses a six-field format with year as the sixth field, and Kubernetes CronJobs use the standard five-field format without seconds. When you copy a cron expression from one platform to another, verify which field format the destination expects — a Quartz expression pasted into a Unix crontab is interpreted completely differently.
This tool works in two directions. As a generator: use the preset buttons (Minutely, Hourly, Daily, Weekly, Monthly) as starting points, or adjust the individual minute, hour, day, month, and day-of-week fields directly to build any schedule. The cron expression field updates in real time as you make selections, and the human-readable description below it updates simultaneously to show exactly what schedule the expression produces in plain English — "At 12:00 AM, only on Sunday" for 0 0 * * 0, or "At every 5th minute" for */5 * * * *. As an explainer: type or paste any existing cron expression directly into the expression field and the tool immediately parses it and displays the plain-English interpretation. This is useful when you encounter a cron expression in a crontab file, a CI/CD pipeline configuration, a cloud scheduler configuration, or a legacy system and need to quickly understand what schedule it represents without manually decoding each field. The architecture guide diagram below the expression shows which part of the expression each position maps to, with the valid ranges for each field clearly labeled. The tool also shows the next scheduled execution times — the upcoming dates and times when the expression would next fire, based on the current time. This lets you verify that the schedule produces the cadence you intend: a schedule that should run every Monday morning should show the next Monday as the first upcoming execution. Seeing the next five execution times immediately reveals off-by-one errors in the day-of-week field, timezone-dependent differences in daily job timing, and edge cases in month-end schedules (February 30 never fires, a schedule for the 31st does not run in February, April, June, September, or November).
1. To generate a cron expression: click one of the preset buttons to start with a common schedule — Minutely (every minute: * * * * *), Hourly (at the start of every hour: 0 * * * *), Daily (at midnight: 0 0 * * *), Weekly (Sunday at midnight: 0 0 * * 0), or Monthly (first day of each month at midnight: 0 0 1 * *). Use these presets as starting points and adjust the individual fields to your specific schedule.
2. Adjust the fields to build your exact schedule — modify the minute field (0-59 or */N for every N minutes), the hour field (0-23 or */N for every N hours), the day-of-month field (1-31 or * for any day), the month field (1-12 or * for any month), and the day-of-week field (0-7 where 0 and 7 both mean Sunday, or use abbreviations MON TUE WED THU FRI SAT SUN). You can use comma-separated values (1,15), ranges (1-5), and step values (*/2) in any field.
3. Read the human-readable description that updates in real time below the expression — this plain-English explanation shows exactly what schedule the current expression produces. Verify the description matches the schedule you intend before copying the expression.
4. To explain an existing cron expression: click into the Cron Expression field at the top and type or paste any cron expression directly. The tool immediately parses it and updates the human-readable description and the field architecture diagram. Use this when you encounter an existing cron expression and need to understand what it does.
5. Copy the generated expression using the Copy button next to the expression field — the cron string is copied to your clipboard ready to paste into your crontab file, CI/CD pipeline configuration (GitHub Actions schedule, GitLab CI schedules), cloud scheduler (AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps), Kubernetes CronJob YAML spec, or any other scheduling system.
Cron syntax is one of those things that every developer who works with servers or automation encounters regularly but rarely commits to memory. The fields are not intuitive — the order (minute, hour, day-of-month, month, day-of-week) is different from how humans describe time, the asterisk wildcard behavior is not immediately obvious, and the interaction between day-of-month and day-of-week fields is a subtle but important behavioral difference across implementations. Most engineers, even experienced ones, keep a cron reference open when writing cron expressions manually. This tool eliminates the need for that reference by making the expression construction visual and showing the English description in real time. The explain direction is where I personally use this tool most. Opening a crontab or a Kubernetes CronJob YAML and seeing 0 3 * * 1 is meaningless until you decode it. Is that 3 AM every Monday, or every first day of the month that happens to be a Monday? (It is 3 AM every Monday regardless of the date.) Does */15 * * * * run at minutes 0, 15, 30, and 45 of every hour, or does it start from some other offset? (It runs at 0, 15, 30, 45 — the step starts from the minimum value of the field.) These interpretations are not obvious from reading the expression string and the plain-English description makes them immediately clear. Scheduling bugs are also some of the most annoying bugs to debug because they only manifest at specific times. A report that is supposed to run daily at midnight UTC does not run in certain timezones because the server runs in UTC and the cron expression was written thinking in UTC+5:30, effectively scheduling the job at 6:30 PM UTC instead of midnight. A monthly cleanup job scheduled for the 31st never runs in months with fewer days. A job scheduled for every quarter using 0 0 1 1,4,7,10 * fails to account for DST transitions in locations that observe daylight saving time. Verifying the schedule with this tool before deploying a cron job prevents these bugs from appearing in production at 3 AM on a weekend.
Real-time plain-English description — the human-readable explanation updates instantly as you build or modify the expression so you always know what schedule the current expression produces
Works in both directions — generate cron expressions visually using presets and field controls OR paste any existing expression to instantly understand what it does
Next execution times shown — displays the upcoming scheduled run times so you can verify the cadence and catch edge cases like schedules that never fire in certain months
Architecture diagram — the field layout guide shows which position maps to which time unit with the valid ranges for each field clearly labeled
Common presets — Minutely Hourly Daily Weekly and Monthly presets provide correct starting expressions that you can customize rather than building from scratch
Covers all standard cron syntax — supports asterisk wildcard comma-separated values range with hyphen and step values with forward slash in all five fields
100% browser-based — your cron schedules and server configuration details never leave your machine
No installation required — paste any cron expression or use the UI to build one immediately with no setup
Generating cron expressions for scheduled GitHub Actions workflows that run on a specific schedule
Creating cron expressions for Kubernetes CronJob specs for periodic batch processing tasks
Building cron schedules for AWS EventBridge scheduled rules for Lambda function invocations
Generating cron expressions for database backup jobs that run nightly or weekly
Explaining existing cron expressions found in legacy crontab files or CI/CD configurations
Creating cron schedules for application cache invalidation jobs that run at off-peak hours
Generating expressions for health check and monitoring jobs that run every few minutes
Building cron schedules for monthly billing jobs report generation or data archiving tasks
Example Input
0 12 * * 1-5
Example Output
Expression: 0 12 * * 1-5 Human-readable: At 12:00 PM (noon), Monday through Friday Field breakdown: Minute: 0 (at minute 0) Hour: 12 (at 12:00 / noon) Day of month: * (every day) Month: * (every month) Day of week: 1-5 (Monday through Friday) Next 5 executions (UTC): Mon 26 May 2026 12:00:00 Tue 27 May 2026 12:00:00 Wed 28 May 2026 12:00:00 Thu 29 May 2026 12:00:00 Fri 30 May 2026 12:00:00
Invalid Syntax — Out of Range Field Value: Each cron field has a valid range. The minute field accepts 0-59, the hour field 0-23, the day-of-month field 1-31, the month field 1-12, and the day-of-week field 0-7. Entering a value outside these ranges — like minute 60, hour 25, or month 13 — is invalid and will be rejected by the cron daemon. Use the UI controls to stay within valid ranges, or check the architecture guide diagram to verify the valid range for each position.
Logical Errors — Schedule That Never Fires: Some cron expressions are syntactically valid but logically impossible. The most common example is scheduling a job for a day-of-month that does not exist in certain months — 0 0 31 * * never runs in February, April, June, September, or November. A job scheduled for 0 0 30 2 * (February 30th) never runs at all because February never has 30 days. The next-execution-times panel reveals this immediately — if no upcoming executions are shown for the next several months, the schedule likely has a date that does not exist.
Timezone Mismatch — Server vs Intended Timezone: Cron daemons run in the server's configured timezone, which is almost always UTC on cloud servers and containers. If you write a cron expression intending it to run at 9 AM in your local timezone (IST UTC+5:30) but the server runs in UTC, you must convert: 9 AM IST is 3:30 AM UTC, so the expression should be 30 3 * * * not 0 9 * * *. Always check your server's timezone with timedatectl on Linux before writing cron expressions. Cloud scheduling services like AWS EventBridge and GCP Cloud Scheduler allow you to specify a timezone explicitly which avoids this conversion entirely.
Day of Month and Day of Week Interaction: When both the day-of-month and day-of-week fields are non-wildcard values, standard cron behavior (Vixie cron and most Unix implementations) is OR not AND — the job runs when either condition is true. So 0 0 15 * 1 runs on the 15th of every month AND also every Monday, not only on Mondays that fall on the 15th. If you want the job to run only on the 15th AND only if it is a Monday, standard cron cannot express this directly — you need to add a conditional check inside the script itself.
Wrong Number of Fields for the Target Platform: Standard Unix cron uses five fields (minute hour day-of-month month day-of-week). Quartz scheduler (Java) uses six fields starting with seconds (second minute hour day-of-month month day-of-week) and supports a seventh year field. AWS EventBridge uses six fields with year as the sixth. Kubernetes CronJobs use the standard five-field format. GitHub Actions uses the standard five-field format. If you paste a six-field Quartz expression into a Unix crontab or GitHub Actions schedule, the expression is misinterpreted with each field shifted one position, producing a completely wrong schedule with no error message.
Confusing the day-of-week field numbering — thinking 1 is Sunday
Fix: In standard Unix cron, the day-of-week field uses 0-7 where 0 and 7 both represent Sunday, 1 is Monday, 2 is Tuesday, 3 is Wednesday, 4 is Thursday, 5 is Friday, and 6 is Saturday. A common mistake is assuming 1 means Sunday (as it does in some calendar systems) and writing 0 0 * * 1 thinking it schedules a Sunday job when it actually schedules a Monday job. Always use the plain-English description in this tool to verify the day name before using the expression. Alternatively, use the three-letter day abbreviations (SUN MON TUE WED THU FRI SAT) in the day-of-week field — they are more readable and unambiguous.
Using */N syntax incorrectly — expecting it to start from a specific offset
Fix: The step syntax */N means starting from the minimum value of the field, incrementing by N. In the minute field, */5 means 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55 — it always starts from 0. If you want to run starting from minute 3 (3, 8, 13, 18, 23...), you cannot use */5 — you need to use 3/5 in cron implementations that support the offset/step syntax, or list the specific minutes explicitly with commas. Not all cron implementations support the offset/step syntax — verify your specific cron daemon's documentation.
Not accounting for Daylight Saving Time transitions in scheduled jobs
Fix: In timezones that observe Daylight Saving Time, the clock jumps forward one hour in spring and back one hour in fall. A job scheduled for 2:30 AM will not run at all on the day the clock skips from 2:00 AM to 3:00 AM, and will run twice on the day the clock falls back from 3:00 AM to 2:00 AM. If your scheduled job is sensitive to running exactly once — a daily billing run, a report generation job — schedule it at a time that is not affected by DST transitions, like 3:00 AM or 4:00 AM when the DST transition has already occurred, or use UTC time on a UTC server to avoid DST entirely.
Writing a cron expression for a GitHub Actions schedule and wondering why it does not fire
Fix: GitHub Actions scheduled workflows have two important behaviors developers frequently miss. First, scheduled workflows only run on the default branch — a schedule trigger on a non-default branch is ignored. Second, GitHub may delay scheduled workflows by up to 15 minutes when GitHub's servers are under load, and schedules that fire less frequently than once per hour may be delayed even longer. Third, if a repository has no recent activity (no commits or workflow runs in 60 days), GitHub disables scheduled workflows to conserve resources — you receive a notification and must re-enable the workflow. If your scheduled workflow is not running, check the repository's Actions tab for any disable notices and verify the workflow is on the default branch.
Setting a cron job to run more frequently than the job itself takes to complete
Fix: If a cron job is scheduled to run every 5 minutes but the job takes 8 minutes to complete, a second instance starts before the first finishes. If the job writes to a shared file, a shared database table, or a shared external service, two simultaneous instances can conflict, corrupt data, or cause API rate limiting. For long-running jobs, schedule them less frequently than their maximum expected duration, add a lock file or a distributed lock mechanism to prevent simultaneous runs, or use a job scheduler that understands job state (like Kubernetes CronJob with concurrencyPolicy: Forbid) rather than raw cron which has no awareness of whether the previous run completed.
Cron Expressions
Quick reference guide for UNIX Cron patterns: minute, hour, day, month, day-of-week, special strings, and automation schedules.
Bash
Quick reference for Bash commands: file operations, piping, process control, environment variables, conditions, and shell scripting loops.
Linux Commands
Interactive handbook for terminal navigation, file administration, permissions, process handling, and basic networking utilities.
Git Cheatsheet
Quick reference guide for essential Git commands, branching workflows, remote repositories, stashing, and rollbacks.
What is a cron expression?
A cron expression is a string of five space-separated fields that defines a recurring schedule for an automated task. Reading from left to right, the fields represent: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7 where 0 and 7 both mean Sunday). The string 0 12 * * 1-5 means 'at minute 0 of hour 12, on any day of the month, in any month, on days 1 through 5 of the week' — which resolves to every weekday at noon. The asterisk in a field means 'every valid value.'
Does it support all cron formats?
The tool supports standard Unix cron syntax (five fields: minute hour day-of-month month day-of-week) which is the format used by Linux crontab, Kubernetes CronJobs, GitHub Actions, GitLab CI schedules, and most cron daemon implementations. It supports the full special character syntax: asterisk for any value, comma for multiple values, hyphen for ranges, and forward slash for step values. Extended formats with six fields (Quartz scheduler with a leading seconds field, AWS EventBridge with a trailing year field) are not the standard five-field format and may be interpreted differently — verify against the next-execution-times output.
Is it safe for sensitive schedules?
Yes. All cron expression parsing and generation runs entirely in your browser using JavaScript. Your cron expressions — including any that encode information about your infrastructure schedule, backup timing, or operational patterns — never leave your machine and are never transmitted to any server. This is relevant for organizations where the timing of certain automated jobs (database backups, security scans, compliance reports) is treated as operationally sensitive information.
How do I schedule a cron job every 15 minutes?
Use */15 in the minute field: */15 * * * *. This runs at minutes 0, 15, 30, and 45 of every hour, every day. The */N step syntax starting from the field's minimum value means 0/15 = 0, 15, 30, 45. If you want every 15 minutes but starting from a specific minute offset (like 3, 18, 33, 48), use 3/15 * * * * if your cron daemon supports offset/step syntax, or list the minutes explicitly: 3,18,33,48 * * * *.
What is the difference between cron day-of-month and day-of-week when both are specified?
When both the day-of-month and day-of-week fields are non-wildcard values, most Unix cron implementations (including Vixie cron and its derivatives) use OR logic — the job runs when either condition is true. So 0 0 15 * 1 runs on the 15th of every month AND also every Monday. It does not mean 'only on Mondays that fall on the 15th.' If you need AND logic (only run on a Monday that is the 15th), standard cron cannot express this — add a date check inside the script: [ $(date +%d) -eq 15 ] && [ $(date +%u) -eq 1 ] && your_command.
How do I use this with GitHub Actions?
GitHub Actions uses standard five-field cron syntax in the schedule trigger. Add a schedule event to your workflow: on: schedule: - cron: '0 12 * * 1-5'. Generate the expression here, verify the human-readable description matches your intended schedule, then copy the expression and paste it inside the quotes in your workflow YAML. Note that GitHub Actions runs all scheduled workflows in UTC, scheduled workflows only run on the default branch, and GitHub may disable scheduled workflows on repositories with no recent activity after 60 days.
How do I write a cron expression that runs on the last day of every month?
Standard Unix cron does not support a 'last day of month' expression because it does not know how many days are in each month. You have two options. First, schedule the job for day 28 which is always valid (0 0 28 * *) though this misses the actual last day in months with 29, 30, or 31 days. Second, use a workaround: schedule the job daily and add a shell check inside the script: [ $(date -d tomorrow +%d) -eq 01 ] && your_command, which runs your command only on the day before the 1st (the last day). Quartz scheduler supports L in the day-of-month field specifically for this purpose.
How do I run a cron job every weekday at 9 AM in my local timezone?
Cron expressions reference the server's configured timezone, which on most cloud servers and containers is UTC. If your intended time is 9 AM IST (UTC+5:30), the UTC equivalent is 3:30 AM UTC — so the expression is 30 3 * * 1-5. If your intended time is 9 AM EST (UTC-5), the UTC equivalent is 2 PM UTC — so the expression is 0 14 * * 1-5. To avoid manual timezone conversion, use a scheduling service that supports explicit timezone configuration: AWS EventBridge scheduled rules, GCP Cloud Scheduler, and Azure Logic Apps all let you specify a timezone directly so you can write the schedule in your local time without UTC math.
Recent Activity
No recent activity