Cron Step Expressions

Cron Step Expressions: How to Use the / Operator

A slash in a cron field means repeat at regular intervals. The operator divides a range into predictable points: */5 in the minute field fires at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55. Without steps, expressing a 5-minute interval would require listing all 12 values: 0,5,10,15,20,25,30,35,40,45,50,55. Steps make complex schedules readable and less error-prone.¹

The step operator combines with either a wildcard or an explicit range. */N divides the field's entire valid range by N, starting at zero. start-end/N divides only the sub-range from start to end by N, which lets you build intervals that skip early-morning or late-night hours. Understanding which starting value the step uses is critical: many users assume */15 starts at minute 1, but it starts at minute 0 because * expands to the range 0 to 59.

How the step operator works

For any field, */N is shorthand for 0-max/N, where max is the field's maximum valid value. In the minute field, */15 expands to 0-59/15, which fires at 0, 15, 30, and 45. In the hour field, */6 expands to 0-23/6, which fires at 0, 6, 12, and 18. The step always starts at the range's minimum value, not at the first match greater than zero.¹ Understanding this start-from-zero behavior is essential when you need triggers offset from the field minimum, because a plain step cannot express that offset on its own.

Confirming step coverage

When combining steps with specific values in other fields, verify the combined schedule with a parser to confirm the expected behavior. A step in the minute field paired with a narrow hour range can produce fewer daily triggers than you assume, especially when the step does not evenly divide the range. Always read the next 10 or 20 trigger times rather than eyeballing the expression, because the interaction between fields is easier to spot in a concrete list of timestamps than in abstract field values.

Also watch for steps that do not divide the field cleanly, because a range such as 0 to 23 with a step of 8 lands on 0, 8, and 16 and then stops short of the top instead of wrapping around. The same expression can therefore fire three times on one platform and feel wrong on another simply because the endpoints are not what you pictured. Validating against the next trigger list makes the actual stop point obvious before the job goes live.

Range-qualified steps

Combining a range with a step restricts when the interval fires. 10-50/10 in the minute field fires at 10, 20, 30, 40, and 50 (never at 0, because the range starts at 10). Building on this, 0 9-17/2 * * * fires at hours 9, 11, 13, 15, and 17 on every day; this pattern suits business-hours polling jobs. The range endpoint is inclusive, so 1-59/2 fires at odd minutes: 1, 3, 5, ..., 59.

Reading the range before the slash

The range before the slash defines the candidate values; the slash then selects every Nth value from that candidate set. This order matters when the range does not start at the field minimum. If the selected points do not match the schedule you intended, change the range before changing the step. For example, 5-55/10 in the minute field fires at 5, 15, 25, 35, 45, and 55, which is useful when you need triggers offset from the hour boundary rather than aligned to it.

Common mistakes with steps

Using */0 as a step is undefined and either causes a parse error or fires continuously depending on the implementation; treat zero as an invalid step in all contexts. A step larger than the field's range (like */100 in the minute field) fires only once, at the start of the range. Consequently, */60 in the minute field fires at minute 0 only.² When combining steps with specific values in other fields, verify the combined schedule with a parser to confirm the expected behavior.

The most common mistake is treating a step as a "every N units" operator without considering the field's maximum value. In the hour field, */8 fires at 0, 8, and 16, which is three times per day, not every 8 hours. Similarly, */9 in the minute field fires at 0, 9, 18, 27, 36, 45, and 54, which is seven times per hour, not once every 9 minutes. Reading the trigger list reveals these patterns instantly, which is why a parser is the safest way to validate a step expression before deploying.

Choosing between a step and an explicit list

When the values you want to trigger on are evenly spaced and start from the field minimum, a step is the right tool. */10 in the minute field fires at 0, 10, 20, 30, 40, and 50, which is exactly what you need for a 10-minute polling interval. When the values are not evenly spaced, or when the interval must not start at zero, a list is clearer and less error-prone.

When a list beats a range-qualified step

If your job must fire at minutes 5, 15, 25, 35, 45, and 55 (aligned to 5 past each hour rather than to the hour), you need 5,15,25,35,45,55 or the range-qualified step 5-55/10, because */10 starts at minute 0, not minute 5. For non-standard offsets, always verify the range-qualified step produces the expected trigger set with a parser before committing it to the crontab.

Step expressions in cloud and platform contexts

On GitHub Actions, Cloudflare Workers, and Kubernetes CronJob, step expressions work identically to standard Unix cron. */5 * * * * fires every 5 minutes on all three platforms, subject to each platform's minimum interval (5 minutes on GitHub Actions,³ 1 minute on Kubernetes⁴ and Cloudflare Workers Paid plan).

For AWS EventBridge cron() expressions, the step operator is available in all fields including the year field.⁵ A step in the year field such as 2024-2030/2 fires only in the listed even years, so it pays to verify a step expression before deploying to AWS; year-field steps are an EventBridge-only feature and produce an error if copied into a standard Unix crontab.

When to use this

Use step expressions when you need a job to repeat at a fixed interval within an hour, day, or week: polling every 5 minutes, refreshing a cache every 15 minutes, or running a health check every 2 hours. If the interval must not start at minute 0 or hour 0, use a range-qualified step, and since step expressions are easy to get subtly wrong, paste yours into a parser and check that the expanded trigger list matches the interval you actually meant.

Examples