Question 1

How do I test and understand a cron expression like 0 9 * * 1-5?

Accepted Answer

Paste it into jslet's Cron Expression Tester. The tool parses the standard 5-field format (minute hour day-of-month month day-of-week) and gives you: (1) a plain-English description — 'At 09:00 AM, Monday through Friday' for 0 9 * * 1-5, (2) the next 10 execution times in your local timezone so you can verify the schedule is correct before deploying, and (3) an estimated monthly execution count — 0 9 * * 1-5 runs ~22 times/month (weekdays). Each field accepts standard cron syntax: * for every value, comma-separated lists (1,3,5), ranges (1-5), step values (*/15 for every 15 minutes), and specific values. If any field is invalid, the tester highlights it in red and explains what's wrong — common errors include using 0 for Sunday in the day-of-week field (0=Sunday in standard cron) or using ranges that exceed the field's maximum value. The tool also links to the cron execution frequency calculator for more detailed scheduling math.

Question 2

Why does my cron job run at unexpected times — what are the most common cron scheduling mistakes?

Accepted Answer

Four cron scheduling mistakes cause the most production surprises. (1) Day-of-month vs day-of-week interaction: when both fields are specified (not *), the job runs when EITHER condition matches — 0 0 1 * 1 runs at midnight on the 1st of every month AND every Monday. To restrict to 'first of the month only if it's Monday', you need wrapper logic in the script, not cron alone. (2) Timezone assumptions: cron runs in the server's system timezone, which may not be UTC. A job scheduled as 0 2 * * * fires at 2 AM server time — if your server is in EST but your team thinks in UTC, that's a 5-hour offset. Always document the timezone explicitly. (3) DST transitions: on 'spring forward' days, a job at 2:30 AM in a DST-observing timezone simply doesn't run — 2:30 AM doesn't exist. On 'fall back,' a job at 1:30 AM runs twice. (4) Overlapping long-running jobs: if a job scheduled every 5 minutes (*/5 * * * *) takes 8 minutes to complete, you'll have multiple instances running simultaneously. Use a lock file or a scheduler that prevents overlap. The cron tester shows you the execution pattern but can't detect runtime duration — always add overlap guards for frequent jobs.

Question 3

What's the difference between crontab format on Linux, cron expressions in Kubernetes CronJobs, and AWS CloudWatch Events?

Accepted Answer

Standard Linux crontab uses 5 fields: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), day-of-week (0-7, where both 0 and 7 = Sunday). Kubernetes CronJobs also use 5 fields in the same order — the syntax is identical to Linux cron. AWS CloudWatch Events (EventBridge) uses 6 fields: minute, hour, day-of-month, month, day-of-week, year — the extra year field is often left as *. AWS also supports rate expressions (rate(5 minutes)) as an alternative. GitHub Actions scheduled workflows use POSIX cron syntax (5 fields) but with a caveat: the shortest interval is 5 minutes, and jobs may be delayed during high load. jslet's cron tester uses the standard 5-field format — if your platform uses 6 or 7 fields (some Quartz schedulers add a seconds field as the first position), strip the seconds field and test the remaining 5 fields. The tool validates each field's range and syntax independently, so you'll see exactly which field has an issue if the expression fails.

`*`	Matches every value. `* * * * *` = every minute.
`5`	Matches exactly 5. `0 5 * * *` = 5:00 AM daily.
`,`	List separator. `0,30 * * * *` = at 0 and 30 minutes past each hour.
`-`	Range. `9-17 * * * 1-5` = hours 9 through 17, Monday through Friday.
`/`	Step. `/15 * * *` = every 15 minutes. Equivalent to `0,15,30,45`.

🟢📖 Cron Expression Syntax