Cron Expression Tool
Parse, generate, and explain cron expressions, preview upcoming runs in any timezone, and pick from common templates, a visual builder, local history, and exports. It is handy for scheduling backend jobs, CI/CD timers, backup windows, report builds, cache refreshes, reminder pushes, and routine service checks.
- Supports both 5-field standard cron and 6-field cron with seconds, and explains the rule in plain language
- Lists the next 5, 10, 20, or 50 runs in the selected timezone, showing both local time and UTC
- Ships with common templates and a visual builder for every minute, hour, day, week, month, and year
- Calls out differences between Linux crontab, GitHub Actions, Cloudflare Workers, Kubernetes, and Quartz
No history yet.
At 09:00, Monday through Friday
| Field | Value | Range |
|---|---|---|
| Minute | 0 | 0 to 59 |
| Hour | 9 | 0 to 23 |
| Day | * | 1 to 31 |
| Month | * | 1 to 12 |
| Weekday | 1-5 | 0 to 6 (0 and 7 are Sunday) |
Syntax notes
Every cron field shares the same handful of symbols, and knowing them removes most hand-written mistakes.
- * Wildcard
- Matches every value in the field. For example, * * * * * fires every minute.
- , Value list
- Lists several specific values in the same field. For example, 0 9,12,18 * * * fires at 09:00, 12:00, and 18:00 every day.
- - Inclusive range
- Matches a contiguous range with both endpoints included. For example, 0 9 * * 1-5 fires at 09:00 on weekdays.
- / Step interval
- Matches at a fixed interval from a starting value or range. For example, */15 * * * * fires every 15 minutes.
- ? Quartz placeholder
- Placeholder for day-of-month or day-of-week meaning the field is left unspecified, supported only by Quartz-style schedulers. For example, 0 0 12 ? * MON fires at noon every Monday.
- L Quartz last value
- Refers to the last value of the field, such as the last day of the month or the last Friday, supported only by Quartz-style schedulers. For example, 0 0 12 L * ? fires at noon on the last day of every month.
- 0/7 Day-of-week values
- In the day-of-week field both 0 and 7 represent Sunday, and most parsers also accept SUN through SAT aliases. So 0 0 * * 0 and 0 0 * * 7 are equivalent, firing at 00:00 every Sunday.
Platform differences
Cron syntax, timezone defaults, and field counts vary between runtimes. Check the target platform docs before deploying.
- Linux crontab
- Uses 5-field standard cron in the system timezone. Declare SHELL, PATH, and MAILTO explicitly inside the crontab to avoid drift from your login shell.
- GitHub Actions
- Only accepts 5-field standard cron and runs in UTC. Scheduled workflows can be delayed or skipped under heavy load or on inactive repos, so back critical timers with another trigger.
- Cloudflare Workers Cron Triggers
- Uses 5-field standard cron in UTC. Each expression must be wired in the Workers configuration, and the minimum granularity is 1 minute.
- Kubernetes CronJob
- Uses 5-field standard cron; spec.timeZone can pin an IANA timezone. Watch startingDeadlineSeconds, concurrencyPolicy, and history limits — they all change what actually runs.
- Quartz Scheduler
- Uses 6 or 7 fields and adds ? L W # extensions. Day-of-month and day-of-week cannot both be wildcards, so one of them must be ?. This tool parses generic cron; verify Quartz-only syntax with its official validator.
Overview
Show a cron expression as plain language, a field-by-field breakdown, and a list of upcoming runs so scheduling, debugging, and pre-launch checks stay grounded.
- 01
Parse and validate 5 / 6-field cron
Detects 5-field standard cron and 6-field cron with seconds automatically and surfaces readable errors right away.
- 02
Description in the current language
Uses cronstrue to print the explanation in the page language, ready for reviews, docs, and tickets.
- 03
Field-level breakdown
Lays out each field — second, minute, hour, day, month, weekday — with its range and the current matching rule.
- 04
Timezone-aware upcoming runs
Lists the next 5, 10, 20, or 50 runs in your local timezone, UTC, or any IANA timezone.
- 05
Templates and a visual builder
Ships templates for every minute, hour, weekday, week, month, and year, plus a builder that assembles a rule by time dimension.
- 06
Local history and exports
Keeps recent expressions in the browser only, and exports the run list as TXT, CSV, or JSON.
How to use
Confirm each field, then verify the preview runs against the target platform timezone before you ship the rule.
- 01
Type a cron expression such as 0 9 * * 1-5, or pick a template if you are not sure where to start.
- 02
Read the plain-language description and the field breakdown to confirm the schedule.
- 03
Pick the target timezone and how many runs to show, then verify the upcoming runs fall in the expected window.
- 04
For more complex rules, open the visual builder and assemble the expression by minutes, hours, day, week, month, or year.
- 05
Copy the expression or export the run list when you are done, and let local history hold the rule for future review.
Details
The tool is shaped around real scheduling work, not a generic cron sandbox.
- Detects 5-field and 6-field cron automatically; an unusual field count is called out instead of silently misparsed.
- Flags possible Quartz-style symbols (? L W #) so you do not reuse them in GitHub Actions, Kubernetes, and friends.
- Warns when both day-of-month and day-of-week are set, since most platforms OR them while a few AND them.
- Upcoming runs show local time, UTC, and time-from-now, which makes daylight-saving and cross-day behavior easy to spot.
- Switching timezones recomputes the run list and is the fastest way to debug UTC-based platforms like GitHub Actions or Cloudflare Workers.
- The visual builder covers minutes, hours, day, week, month, and year, with weekday and month pickers when relevant.
- Parsing, scheduling, copy, and export run locally in the browser; expressions never leave your machine.
Use cases
Cron is the lingua franca of scheduled work. Almost any periodic task ends up written in it.
-
Backend scheduled jobs
Pick the cadence for billing, renewals, report builds, cleanup scripts, and cache warming.
-
CI/CD and build sweeps
Schedule UTC-aligned nightly builds, regression tests, and dependency scans on GitHub Actions, GitLab CI, and Jenkins.
-
Data sync and archival
Set the window for database sync, log archiving, ETL runs, backup strategies, and warehouse refreshes.
-
Ops checks and alerts
Schedule health checks, disk-space scans, certificate expiry sweeps, and on-call reminder pushes.
-
Messaging and growth automation
Drive morning digests, stand-up summaries, campaign kickoffs, sale closeouts, and reactivation emails.
-
Cloud-native and container schedules
Validate expressions and timezones for Kubernetes CronJob, Cloudflare Workers, Vercel Cron, and Lambda schedules.
-
IoT and edge tasks
Plan device polling, gateway uploads, cache flushes, and remote upgrade windows.
-
Team docs and code review
Drop a readable cron explanation into docs, PR descriptions, and tickets instead of guessing the rhythm.
See also
To turn an upcoming run into Unix seconds or milliseconds, use the Timestamp Converter . When the same run has to land in several cities, the Timezone Converter lays it out side by side. To watch live wall-clock time across regions while you reason about a schedule, open the World Clock alongside this tool.
Best practices
Reliable scheduled jobs come from explicit timezones, a readable description of the rhythm, and a real run-time check.
- Verify the rhythm against the upcoming-run preview before shipping; do not rely on the description alone.
- For distributed teams, record the cron expression, target timezone, and a couple of concrete run examples together.
- On UTC platforms like GitHub Actions and Cloudflare Workers, convert your local target time to UTC before writing the expression.
- When both day-of-month and day-of-week are set, check the target platform docs to know whether it is OR or AND.
- For high-frequency rules (such as every minute), make the job idempotent and watch for backlog under upstream load.
- For complex rules, keep the expression in source control or a config service with a short comment about intent.
Limitations
Cron is an expression language; implementations differ in the small details. This tool only explains expressions and never schedules anything.
- The tool only parses and previews. It never registers or triggers a job on any platform.
- GitHub Actions, Cloudflare Workers, and many other platforms only accept 5-field cron in UTC; 6-field (with seconds) is not available there.
- Quartz extensions (? L W #) are not available in most generic cron parsers; for Quartz, validate with its official tooling.
- During daylight-saving transitions, a missing or repeated hour can change how often the job runs. Preview runs that cross the transition day.
- When both day-of-month and day-of-week are set, the matching semantics differ between platforms; use the target docs as the source of truth.
- Upcoming runs are calculated in the browser using the selected IANA timezone and do not guarantee what production will fire. Verify on the target platform too.
FAQ
Answers covering field counts, timezones, platform compatibility, Quartz, and history.
Why are some cron rules five fields and others six?
Traditional Unix crontab uses five fields (minute, hour, day, month, weekday). Quartz, Spring, and cron-parser support a six-field form that adds a seconds field at the front. The tool detects the format from the field count automatically.
Why does parsing fail?
Usually the field count is wrong, a value is out of range, or the expression uses syntax that the runtime does not support (such as Quartz ? L W #). The field range and syntax notes are the best places to check.
Are 0 0 * * 0 and 0 0 * * 7 the same?
Yes. In the day-of-week field, both 0 and 7 mean Sunday, and most parsers also accept SUN–SAT aliases.
What happens when day-of-month and day-of-week are both set?
Most Unix-style runtimes use OR (fire when either matches); a few use AND (fire only when both match). Verify with the target platform docs, or split the rule into two separate cron entries.
Why are my GitHub Actions runs late?
GitHub Actions runs in UTC and may delay or skip runs during peak load, and inactive repositories can have schedules paused. Back critical timers with another trigger or a retry path.
Does this tool actually create scheduled jobs?
No. It parses, explains, and previews runs locally in the browser. It never calls any platform API and never uploads expressions.
Is the history uploaded?
No. History lives in browser localStorage and is only visible in your current browser and origin. You can remove individual entries or clear the whole list at any time.
Why does the run count change at daylight-saving transitions?
Daylight-saving transitions skip or repeat a stretch of time. A cron rule that targets that hour can fire one extra time or miss a run. Preview the runs around the transition day to confirm the behavior.
Related tools
Continue with timestamp conversion, timezone conversion, world clock, and date calculator tools for logs, scheduling, billing periods, and cross-timezone work.