A standard cron expression has five fields — minute, hour, day-of-month, month, day-of-week — each of which can be a literal number, a wildcard (*), a range (9-17), a step (*/15), or a comma-separated list. Reading one at a glance is a skill that doesn't transfer well between engineers, which is exactly why a plain-English translation is more useful than the raw string in a code review or an incident postmortem.
The two fields that trip people up are day-of-month and day-of-week, because cron treats them with an implicit OR when both are restricted (not wildcards): an expression like 0 0 1 * 1 means midnight on the 1st of the month OR every Monday, not the 1st of the month if it happens to be a Monday. This is the single most common source of 'why did this job run twice' incidents in cron-based scheduling.
Impossible schedules are a real and surprisingly common bug class. 0 0 30 2 * asks for February 30th, which never exists in the Gregorian calendar — the job silently never fires, and because cron doesn't error on invalid-but-syntactically-valid dates, this can sit unnoticed for months. On the other end, an expression like * * * * * fires every minute, and a step value like */1 in the minute field is equivalent and just as aggressive — worth flagging if the intent was a coarser interval.
This parser expands each field, builds a plain-English description, computes the next five fire times from the current moment, and checks for the never-fires and fires-too-often patterns before you deploy the schedule.
Edge cases worth knowing
- Day-of-month and day-of-week both restricted
- 0 9 15 * 1 means 9am on the 15th OR every Monday at 9am — not 9am on the 15th if it's a Monday. Most people read it as AND. This parser's plain-English output makes the OR explicit.
- An expression that targets February 30th or 31st
- 0 0 30-31 2 * is syntactically valid cron but mathematically impossible — February never has 30 or 31 days. The job compiles, deploys, and never runs, which is worse than an error because nothing alerts you.
- A step value smaller than the field's natural granularity
- */1 in the minute field literally means every minute — the same as a bare *. It's not wrong, but it usually signals someone meant */10 or */15 and fat-fingered the value.
Common mistakes
- Reading a restricted day-of-month AND day-of-week as an intersection when cron treats it as a union.
- Scheduling a job for the 29th, 30th, or 31st without accounting for months that don't have that day.
- Confusing 0 0 * * * (midnight daily) with 0 0 0 * * (an invalid hour field, since hours run 0–23) in hand-written expressions.
- Not accounting for the server's timezone — a cron daemon set to UTC will fire at a different wall-clock time than one set to local time.