Free Cron Expression Generator
Create cron expressions using visual dropdowns, presets, or paste an existing expression to decode it in plain English instantly. Supports standard 5-field cron syntax (minute, hour, day of month, month, day of week) used by crontab on Linux and macOS, GitHub Actions schedule triggers, Kubernetes CronJobs, GitLab CI pipeline schedules, Jenkins, AWS EventBridge, and Google Cloud Scheduler. The built-in cheat sheet covers every special character including asterisk, slash, hyphen, and comma, plus shortcut strings like @daily, @weekly, and @monthly. Runs entirely in your browser with no server calls, no signup, and no data collection — completely private by design.
Loading...
Need expert help with AI?
Looking for a specialist to help integrate, optimize, or consult on AI systems? Book a one-on-one technical consultation with an experienced AI consultant to get tailored advice.
What Is a Cron Expression?
Cron is the standard job scheduler on Unix-like operating systems, originally created in the 1970s and still the universal way to define recurring schedules. A cron expression is a compact string of five space-separated fields that tells the system exactly when to run a task: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). Four special characters provide flexible scheduling — asterisk (*) matches every value, slash (/) sets step intervals like "every 15 minutes," hyphen (-) defines ranges like "Monday through Friday," and comma (,) creates lists like "the 1st and 15th."
Cron syntax is used far beyond the original Unix crontab. Kubernetes CronJobs, GitHub Actions scheduled workflows, GitLab CI pipeline schedules, Jenkins build triggers, AWS EventBridge rules, Google Cloud Scheduler, and Azure Logic Apps all accept cron expressions to define when jobs should fire. Many cron implementations also support shortcut strings like @daily (equivalent to "0 0 * * *"), @weekly, @monthly, @yearly, @hourly, and @reboot for common scheduling patterns. This tool helps you build, visualize, and decode cron expressions without memorizing the syntax, with a built-in cheat sheet and plain-English descriptions that update as you select values.
Cron Across Platforms: Differences That Matter
While the 5-field cron format is nearly universal, each platform adds its own quirks. GitHub Actions interprets all cron schedules in UTC with no timezone override and enforces a minimum interval of 5 minutes — scheduled runs during peak load may also be delayed. Kubernetes CronJobs use standard 5-field cron but since version 1.27 support a spec.timeZone field for explicit timezone control, with automatic DST handling that skips jobs in non-existent hours and deduplicates jobs in repeated hours. GitLab CI uses the fugit library to parse cron and supports extended syntax like # for nth-weekday and % for step-based day-of-week. Jenkins adds an H symbol that hashes the job name to spread load across an interval.
AWS EventBridge uses a 6-field cron format (adding a year field) wrapped in cron() syntax and requires a ? wildcard in either the day-of-month or day-of-week field — you cannot specify both simultaneously. Google Cloud Scheduler uses standard 5-field unix-cron and also accepts named months (JAN-DEC) and named days (SUN-SAT) alongside numeric values. Quartz cron, used in Java and Spring applications, is the most different — it uses 6-7 fields starting with seconds, numbers days of the week 1-7 instead of 0-6, and adds special characters like L (last), W (nearest weekday), and # (nth occurrence). Expressions generated by this tool are standard 5-field format and work directly with crontab, GitHub Actions, Kubernetes, GitLab CI, Google Cloud Scheduler, and most CI/CD systems.
Timezone Pitfalls, Debugging Tips, and Cron vs Systemd Timers
The most common reason cron jobs run at unexpected times is a timezone mismatch. Cron uses the system timezone by default, so a server set to UTC will interpret "0 9 * * *" as 9 AM UTC — not your local time. The safest approach is to standardize all servers on UTC and calculate offsets in your head or with a converter. Daylight saving time adds another trap: jobs scheduled between 1 AM and 3 AM in DST-observing timezones may be skipped entirely during the spring-forward transition or executed twice during the fall-back transition. Avoid scheduling critical jobs in the 1-3 AM window, or use platforms like Kubernetes that handle DST transitions automatically.
When debugging a broken cron schedule, start by verifying the expression in this tool to confirm it matches your intent. Common mistakes include confusing the field order (minute is first, not hour), using 7 for Sunday when your system expects 0, and assuming day-of-month and day-of-week create an AND condition when they actually create an OR (a schedule with "15" in the day-of-month and "1" in the day-of-week runs on the 15th AND every Monday, not on Mondays that fall on the 15th). On Linux, check cron daemon status, review logs in /var/log/syslog or journalctl, and remember that cron runs with a minimal PATH — always use absolute paths for scripts and binaries. For teams on modern Linux servers who need richer scheduling, systemd timers offer built-in logging via journald, concurrency protection, missed-job catch-up with Persistent=true, and dependency management — at the cost of requiring two configuration files per scheduled task instead of a single crontab line.
More Free Tools
How It Works
Select minute, hour, day, month, and weekday from dropdowns or pick a preset.
See the cron expression and plain-English description update live.
Copy the expression or paste one to decode it.
Key Features
Privacy & Trust
Use Cases
Frequently Asked Questions
Is this Cron Generator free?
Yes, it is completely free with no usage limits, no signup, and no ads. Cloud-based cron tools and scheduling services often charge monthly fees, but because this tool runs entirely in your browser with pure client-side JavaScript, there are no server costs. You can build and decode as many cron expressions as you need without paying anything.
What is a cron expression and what are the 5 fields?
A cron expression is a compact string of five space-separated fields that defines a recurring schedule: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). Each field accepts specific values, ranges, lists, and step values. For example, "30 9 * * 1-5" means "at 9:30 AM every Monday through Friday." Cron was originally created for the Unix operating system in the 1970s and remains the universal standard for time-based job scheduling across Linux, macOS, Kubernetes, CI/CD platforms, and cloud services.
What do the special characters *, /, -, and , mean in cron?
The asterisk (*) matches every possible value for that field — so * in the hour field means every hour. The slash (/) defines step values — */15 in the minute field means every 15 minutes (at 0, 15, 30, and 45). The hyphen (-) defines an inclusive range — 1-5 in the day-of-week field means Monday through Friday. The comma (,) creates a list of specific values — 1,15 in the day-of-month field means the 1st and 15th. These four characters can be combined for complex schedules like "0 */2 1-15 * *" which runs every 2 hours on the first 15 days of every month.
What are @daily, @weekly, @monthly, and the other cron shortcut strings?
Many cron implementations support predefined shortcut strings that replace the five-field syntax for common schedules. @yearly (or @annually) is equivalent to "0 0 1 1 *" — once a year at midnight on January 1st. @monthly equals "0 0 1 * *" — midnight on the first of every month. @weekly equals "0 0 * * 0" — midnight every Sunday. @daily (or @midnight) equals "0 0 * * *" — once a day at midnight. @hourly equals "0 * * * *" — at the start of every hour. @reboot runs once when the cron daemon starts. These shortcuts are supported by most Linux crontab implementations, but not all platforms support them — GitHub Actions and Kubernetes CronJobs, for example, require the standard five-field format.
What is the difference between standard cron and Quartz or Spring cron?
Standard Unix cron uses 5 fields (minute, hour, day, month, weekday), while Quartz cron (used in Java applications and Spring Framework) uses 6 or 7 fields by adding a seconds field at the beginning and an optional year field at the end. Quartz also introduces special characters not found in standard cron: ? (no specific value, required in either day-of-month or day-of-week), L (last day of month or week), W (nearest weekday), and # (nth weekday of the month, e.g., 6#3 means the third Friday). Quartz also numbers days of the week 1-7 (Sunday=1) instead of 0-6 (Sunday=0). This tool generates standard 5-field cron, which is compatible with crontab, GitHub Actions, Kubernetes, and most CI/CD systems. If you need Quartz format, you will need to prepend a seconds field (usually 0) and adjust the day-of-week numbering.
Can I use this for GitHub Actions scheduled workflows?
Yes. GitHub Actions uses standard 5-field cron syntax in the schedule trigger of workflow YAML files. Build your expression here and paste it into the cron field under "on: schedule:" in your workflow. Be aware that GitHub Actions cron schedules always run in UTC with no timezone configuration — if you need a job at 9 AM in your local timezone, you must calculate the UTC offset yourself. Also note that GitHub Actions has a minimum interval of 5 minutes and that scheduled runs may be delayed during periods of high load on GitHub infrastructure.
Can I use this for Kubernetes CronJobs?
Yes. Kubernetes CronJobs use standard 5-field cron syntax in the spec.schedule field of the CronJob manifest. Build your expression here and paste it directly into your YAML. Since Kubernetes 1.27, CronJobs support a spec.timeZone field where you can specify a timezone like "America/New_York" or "Europe/London" — this is the recommended approach instead of relying on the cluster default. Kubernetes handles daylight saving time transitions automatically: jobs scheduled during a skipped hour (spring forward) are skipped entirely, and jobs during a repeated hour (fall back) run only once.
Can I use this for GitLab CI, Jenkins, or other CI/CD systems?
Yes. GitLab CI pipeline schedules, Jenkins build triggers, CircleCI scheduled workflows, and most CI/CD platforms use standard 5-field cron syntax. In GitLab, you configure schedules under Build > Pipeline schedules using cron notation with timezone selection. Jenkins uses cron in its "Build periodically" trigger and adds an H symbol that distributes load by hashing the job name. The expressions generated by this tool work directly in all of these systems — just copy and paste.
How does AWS EventBridge cron differ from standard cron?
AWS EventBridge uses a 6-field cron format: minute, hour, day-of-month, month, day-of-week, and year — wrapped in cron() syntax like cron(0 9 * * ? *). The key differences are the added year field, the requirement to use ? (no specific value) in either the day-of-month or day-of-week field (you cannot specify both simultaneously), and the cron() wrapper. EventBridge also supports rate() expressions like rate(5 minutes) for simple intervals. To convert an expression from this tool to EventBridge format, add a year field (* for every year), replace * with ? in one of the day fields, and wrap it in cron().
Does Google Cloud Scheduler use the same cron syntax?
Google Cloud Scheduler uses standard unix-cron 5-field format, so expressions from this tool work directly. Cloud Scheduler also accepts named months (JAN-DEC) and named days (SUN-SAT) in addition to numbers, and treats both 0 and 7 as Sunday. Each Cloud Scheduler job has an explicit timezone setting, avoiding the UTC-only limitation of GitHub Actions. Google also offers an alternative human-readable format called App Engine cron syntax for simpler schedules.
Why do my cron jobs run at the wrong time? How do I handle timezones?
The most common cause of cron jobs running at unexpected times is a timezone mismatch. By default, cron uses the system timezone of the server it runs on, which may differ from your local timezone. The safest practice is to set all servers and cron daemons to UTC, then calculate the UTC equivalent of your desired local time. Be especially careful with daylight saving time (DST): jobs scheduled between 1-3 AM in timezones that observe DST may be skipped (spring forward) or run twice (fall back). On Linux you can set CRON_TZ at the top of your crontab to force a specific timezone. Kubernetes CronJobs support spec.timeZone natively since v1.27. GitHub Actions is always UTC with no timezone override.
What is the difference between cron and systemd timers?
Cron and systemd timers are both Linux task schedulers, but they differ in several ways. Cron is simpler — you edit a single crontab file with one-line schedule entries. Systemd timers require two files (a .timer unit and a .service unit) but offer significant advantages: automatic logging via journald, built-in concurrency protection that prevents overlapping runs, the ability to catch up on missed jobs with Persistent=true, dependency management so tasks wait for required services, and on-demand execution with systemctl start. Cron remains the better choice for simple, portable scheduling across Unix-like systems, while systemd timers are preferred on modern Linux servers where you need monitoring, logging, and dependency management out of the box.
How do I debug a cron expression that is not working?
Start by verifying the expression itself — paste it into this tool to see the plain-English description and confirm it matches your intent. Common mistakes include confusing field order (minute comes first, not hour), using 0-indexed vs 1-indexed values incorrectly (day-of-week 0 is Sunday, month 1 is January), and forgetting that * in day-of-week and day-of-month creates an OR condition, not an AND. On a Linux server, check that your cron daemon is running with "systemctl status cron", review cron logs in /var/log/syslog or /var/log/cron, and ensure your script uses absolute paths for all binaries and files since cron runs with a minimal PATH environment variable.
What are some common cron expression examples?
Here are frequently used expressions: "* * * * *" runs every minute. "*/5 * * * *" runs every 5 minutes. "0 * * * *" runs at the top of every hour. "0 9 * * *" runs daily at 9 AM. "0 9 * * 1-5" runs at 9 AM on weekdays only. "0 0 * * 0" runs at midnight every Sunday. "0 0 1 * *" runs at midnight on the first of every month. "0 0 1 1 *" runs once a year on January 1st. "30 2 * * *" runs at 2:30 AM daily — a popular time for backups and maintenance tasks because traffic is typically lowest.
Can cron expressions handle "last day of the month" or "second Tuesday"?
Standard 5-field cron cannot express "last day of the month" or "nth weekday of the month" directly — these require extensions found in Quartz cron (L for last, # for nth occurrence) or platform-specific features. For the last day of the month in standard cron, a common workaround is to run a script that checks the current date and exits early if it is not the last day. Some platforms like AWS EventBridge support L in the day-of-month field natively. For "second Tuesday" scheduling, Quartz uses "3#2" (day 3 = Tuesday in Quartz numbering, #2 = second occurrence), but this is not available in standard cron.
Limitations
- Standard 5-field cron only (no seconds or year fields)
- Does not support Quartz or Spring cron format (6-7 fields)
- Does not predict next execution times
- Does not support named months or days (JAN, MON)
Q&A SESSION
Got a quick technical question?
Skip the back-and-forth. Get a direct answer from an experienced engineer.
