Cron Schedule Builder
Build, validate, and translate five-field Unix cron schedules.
0–59
24-hour clock, 0–23
Unix five-field dialect: minute, hour, day of month, month, day of week. Quartz tokens are not supported.
Valid five-field expression.
Plain English
Every day at 08:30.
Field anatomy
30
minute
8
hour
*
day
*
month
*
weekday
Execution note
Cron timing uses the timezone and day-of-month/day-of-week behavior of the scheduler that runs it. Confirm those rules before production use.
*Every allowed value,Value list-Inclusive range/Step intervalWorking notes
Use Cron Schedule Builder with the boundary visible.
Cron Schedule Builder assembles and validates conventional five-field Unix cron expressions and translates them into a readable schedule summary.
What is Cron Schedule Builder?
A cron expression is a compact string that defines a recurring schedule. It originated in Unix cron, the time-based job scheduler present on every Linux and macOS system since the 1970s. The standard format uses five fields separated by spaces: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC), and day of week (0-6 or SUN-SAT, where 0 is Sunday). Each field can be a specific value, a range (1-5), a list (1,3,5), a step (*/15 means every 15th value), or an asterisk (every value). Cron expressions are now used far beyond Unix: Kubernetes CronJobs, GitHub Actions schedules, AWS EventBridge rules, Airflow DAGs, and CI/CD pipelines all use cron syntax to trigger jobs. Despite its ubiquity, cron syntax is notoriously easy to get wrong — a misplaced field can schedule a job hourly instead of daily, or fire on the wrong day of the week. A cron builder tool lets you construct the expression visually and immediately see the human-readable schedule it produces, catching mistakes before they reach production.
When to use it
- Scheduling CI/CD pipelines — build the cron expression for a nightly build, weekly dependency audit, or end-of-month report before pasting it into your GitHub Actions or GitLab CI config.
- Configuring Kubernetes CronJobs — write the schedule for a database backup, log rotation, or health check that runs at specific business hours or maintenance windows.
- Setting up monitoring alerts — define when periodic checks should run (e.g., every 5 minutes during business hours, hourly on weekends).
- Planning batch processing — schedule ETL jobs, data syncs, or email digests at times that avoid peak traffic.
- Debugging existing schedules — paste a cron expression from an existing config file to verify that it fires when you expect it to.
How to use it
- 01Use the visual picker to select values for each field: minute, hour, day of month, month, and day of week.
- 02Alternatively, type a raw cron expression directly and the builder parses and validates it.
- 03Read the human-readable schedule summary to confirm the expression matches your intent.
- 04Copy the expression into your scheduler config. Remember that the timezone is determined by the scheduler, not the expression.
Common mistakes
- Confusing field order — the five fields are minute, hour, day, month, weekday. A common mistake is putting the hour first (as in everyday language) instead of the minute.
- Forgetting that 0 is Sunday — in standard Unix cron, day-of-week 0 is Sunday and 6 is Saturday. Some systems (like Quartz) use 1 for Sunday.
- Using Quartz syntax in Unix cron — Quartz adds a seconds field (6-7 fields total) and uses different day-of-week numbering. A Quartz expression will misfire in Unix cron.
- Ignoring timezone — cron expressions have no timezone. The scheduler (crontab, Kubernetes, AWS) determines which timezone the schedule runs in. Always verify the timezone setting.
- Overlapping day-of-month and day-of-week — in standard cron, if both fields are set (not *), the job runs when either condition matches (OR logic), not both (AND logic). This surprises most users.
Synthetic example
Weekdays at 08:30
Input
30 8 * * 1-5
Result
At 08:30 on every weekday.
Cron syntax across platforms
| Feature | Unix cron | Kubernetes | GitHub Actions | AWS EventBridge |
|---|---|---|---|---|
| Fields | 5 (min-wday) | 5 (min-wday) | 5 (min-wday) | 6 (min-year) |
| Seconds field | No | No | No | No |
| Year field | No | No | No | Yes (optional) |
| Sunday | 0 or 7 | 0 or 7 | 0 or 7 | 1 |
| Timezone | System TZ | Pod TZ (UTC default) | UTC only | UTC (configurable) |
| Day logic | OR (day/wday) | OR | OR | AND |
Related standards
Limits and data boundary
- The tool targets five-field Unix cron, not Quartz seconds/year extensions.
- Timezone and daylight-saving behavior belong to the scheduler that executes the expression.
Frequently asked questions
- What are the five fields in a cron expression?
- Minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, Sunday=0). Asterisks mean "every value."
- Does this support Quartz or AWS cron syntax?
- No. This tool targets the standard five-field Unix cron format. Quartz (six or seven fields with seconds and years) and AWS (six fields) are not supported.
- What timezone does the schedule use?
- The tool shows the expression and its meaning but does not determine the timezone. The scheduler that runs the job (crontab, Kubernetes, GitHub Actions) controls the timezone.
- What does */5 mean?
- The step syntax */5 means "every 5th value." In the minute field, */5 fires at minutes 0, 5, 10, 15, ..., 55.
- How do I schedule a job for the last day of the month?
- Standard cron has no "last day" syntax. Common workarounds include scheduling on the 28th (misses some months), using a wrapper script that checks the date, or using a scheduler that supports L syntax (like Quartz).
Keep working