Cron field reference
| Field | Range | Special |
|---|---|---|
| Minute | 0-59 | * , - / |
| Hour | 0-23 | * , - / |
| Day of month | 1-31 | * , - / |
| Month | 1-12 | * , - / |
| Day of week | 0-6 (Sun=0) | * , - / |
Syntax cheatsheet
*: every value in the range5: exact value1-5: range (inclusive)1,3,5: list*/5: every 5 starting from 00-30/10: every 10 from 0 to 30
The day-of-month / day-of-week gotcha
When both day-of-month and day-of-week are restricted (not *), POSIX cron matches if
either is satisfied, they're OR'd, not AND'd. So 0 0 15 * 1 means "midnight on the
15th of every month OR every Monday," which is probably not what you intended.
This tool uses the POSIX OR rule (consistent with cron, Jenkins, etc).
Cron pitfalls
- Timezone: classic Linux cron runs in the server's local timezone. DST transitions can make a job run twice or skip a run. For safety, set the machine to UTC or use a scheduler that supports explicit timezones (systemd timers, Quartz).
- Missed runs: if the machine is off at the scheduled time, the run is gone. Use
anacronor a job runner with catch-up semantics. - Overlap: if your job takes longer than the interval, you'll end up with concurrent runs. Wrap in a lock file or use a scheduler that prevents overlap.
- Seconds: standard cron doesn't have a seconds field. If you see a 6-field cron, it's a non-standard extension (Quartz, some JS libraries). This tool is 5-field POSIX.
Common cron schedules
| Expression | Nickname | Meaning |
|---|---|---|
0 * * * * | @hourly | Every hour at :00 |
0 0 * * * | @daily | Every day at midnight |
0 0 * * 0 | @weekly | Every Sunday at midnight |
0 0 1 * * | @monthly | First of every month at midnight |
*/5 * * * * | : | Every 5 minutes |
*/15 * * * * | : | Every 15 minutes |
0 9-17 * * 1-5 | Business hours | Top of every hour, Mon-Fri 9 AM-5 PM |
0 0 1 * * | First of month | Midnight on the 1st of each month |
0 8 * * 1-5 | Weekdays only | 8 AM every weekday |
0 0 * * 0 | Sunday midnight | Weekly cleanup run |
Cron vs systemd timers vs cloud schedulers
Classic Linux cron isn't the only game in town. Here's how the major options compare:
| Scheduler | Timezone support | Missed-run handling | Complexity |
|---|---|---|---|
| Linux cron | Server TZ only | Skipped silently | Low |
| systemd timers | Any TZ via OnCalendar | Catch-up with Persistent=true | Medium |
| AWS EventBridge | UTC + rate/cron expressions | At-least-once, retries configurable | Medium |
| GCP Cloud Scheduler | Any IANA TZ | Configurable retry policy | Medium |
| GitHub Actions schedule | UTC only | Skipped if repo inactive 60 days | Low |
Platform-specific cron differences
The 5-field standard isn't universal. Know the quirks before you deploy:
- GitHub Actions: uses standard 5-field POSIX cron in UTC. The
?wildcard (used in Quartz to mean "no specific value") is not supported: use*instead. Note that GitHub queues scheduled runs when runners are busy; actual run time can be 15-30 minutes late under load. - Kubernetes CronJob: standard 5-field cron. The
startingDeadlineSecondsfield controls how many seconds past the scheduled time a job can still be started, set it or missed jobs are silently dropped. - Quartz Scheduler (Java): 6-field: seconds, minutes, hours, day-of-month, month, day-of-week. The
?is required in either day-of-month or day-of-week to avoid ambiguity. So0 30 9 ? * MON-FRImeans 9:30 AM weekdays. - AWS EventBridge: supports both rate expressions (
rate(5 minutes)) and cron expressions. EventBridge cron is 6-field (adds year), uses?like Quartz, and runs in UTC. The format iscron(minutes hours day-of-month month day-of-week year). - Node.js / node-cron: optionally 6-field with seconds as the first field. Check your library docs, some default to 5-field, others to 6-field.
FAQ
Does this support 6-field (with seconds) expressions?
No, 5-field POSIX only. If you see 0 0 12 * * ?, that's Quartz format. Drop the first (seconds) field and replace ? with * to convert to standard cron: 0 12 * * *.
Does it support @daily / @hourly?
The tool uses equivalent numeric expressions. @hourly equals 0 * * * *, @daily equals 0 0 * * *, @weekly equals 0 0 * * 0, and @monthly equals 0 0 1 * *. Use the preset dropdown to jump straight to these.
How do I handle timezones in cron?
Classic cron has no timezone awareness, it runs in whatever TZ the server is set to. The safest approach is to run your server in UTC and do the timezone math yourself. If you need user-timezone-aware scheduling, switch to a scheduler that supports IANA timezone strings: systemd OnCalendar, GCP Cloud Scheduler, or a library like Quartz. This tool shows next run times in your browser's local timezone for reference.
How do I test a cron expression before deploying?
Use this tool's "next 5 run times" output to verify the schedule looks right. For a more exhaustive check, pipe the expression through croniter (Python) or node-cron's validate() method. For GitHub Actions, push to a test branch and watch the Actions tab, you can also trigger a scheduled workflow manually with workflow_dispatch to confirm the job works before the first real run.
Pillar
Reference pages
- Cron expression examples: every minute, hour, day and week with syntax for crontab, GitHub Actions and Kubernetes.