Summary

This cron expression generator turns a schedule description, or a pasted cron string, into a validated 5-field expression: minute, hour, day of month, month, and day of week. Pick a common preset like every 5 minutes or weekdays at 9 AM, or edit each field directly, with support for ranges, lists, and step values. The tool renders a plain-English description of the schedule and computes the next five run times in UTC, using the same day-of-month and day-of-week OR logic that vixie-cron and Kubernetes CronJob use, so what you see here matches what actually fires in production.

Cron Expression Generator for Scheduled Jobs and Rollout Windows

Build a 5-field cron expression from presets, or paste one to check it. Get a plain-English description and the next five run times before the schedule ships.

Build a schedule

Cron expression generator

Pick fields or a preset below. The expression, a plain-English description, and the next five run times update as you type.

Common schedules
0 9 * * 1-5

Under the hood

How this cron expression generator works

Five fields, standard syntax

Minute, hour, day of month, month, and day of week: the same fields crontab, GitHub Actions schedule, and Kubernetes CronJob all read. Ranges (9-17), lists (1,15,30), steps (*/5), and wildcards parse the same way they do in production.

Day fields are OR'd, not AND'd

Set day of month to 1 and day of week to Monday, and the job runs on the first of the month or on any Monday, not only when both line up. That's how vixie-cron and Kubernetes CronJob actually evaluate it, and it's the detail most generators skip.

Next five runs, computed live

Every edit recalculates five UTC timestamps by walking forward through the real calendar, so a schedule that can never fire, like day 30 in February, shows up empty here instead of silently sitting dead in a crontab.

Paste to check, not just to build

Already have a cron string from a teammate, a CronJob manifest, or an old Stack Overflow answer? Paste it into the field and get the same description and run times, no separate validator needed.

How to use it

From blank fields to a schedule you trust

  1. 1

    Start from a preset

    Pick a common schedule (every 5 minutes, weekdays at 9 AM, monthly on the 1st), or leave the defaults and adjust from there.

  2. 2

    Adjust the fields that matter

    Use the quick-pick dropdowns or type directly: comma lists, dashes for ranges, and */N for steps all work in every field.

  3. 3

    Confirm before you ship it

    Read the plain-English description and check the next five run times against your maintenance window or SLO budget, then copy the expression into your crontab, CI schedule, or CronJob manifest.

Implementation detail

Why the day-of-month and day-of-week fields use OR logic

POSIX/vixie-cron, the implementation behind Linux crontab and Kubernetes CronJob, has an odd rule most people never read past. If both the day-of-month and day-of-week fields are restricted away from *, the job runs when either one matches, not only when both do. Set day-of-month to 1 and day-of-week to Monday, and the schedule fires on the first of the month and on every Monday, not only on a Monday that happens to be the first. Leave either field as *, and only the restricted one constrains the day. This generator follows that convention because it is what actually runs your crontab, not a simplified version of it. It matters most for the kind of schedule a platform team writes at 11 PM: run this on the first business day, or the first of the month, whichever comes first, looks like an AND to most people and behaves like an OR in production.

  • POSIX/vixie-cron (Linux crontab, Kubernetes CronJob): OR once either day field is restricted
  • Quartz cron (common in Java-based schedulers): usually requires one of the two day fields to stay as ? instead of *, avoiding the ambiguity entirely
  • This generator follows the POSIX/vixie-cron convention, since that is what crontab and CronJob actually execute
Macro shot of an analog clock face with gears in front of a blurred server rack

Common questions

Is this cron expression generator free?
Yes. It runs entirely in your browser, no account, no rate limit, and no data sent anywhere except an anonymous page-view beacon.
What timezone are the next run times shown in?
UTC. Most crontabs, GitHub Actions schedules, and Kubernetes CronJob resources default to UTC or the container's system time, so this avoids a timezone conversion error. Confirm your own system's timezone before you rely on the exact minute.
Why does day-of-month 1 and day-of-week Monday run on both, not just when they overlap?
Because that is how cron itself behaves. Standard vixie-cron implementations, including Linux crontab and Kubernetes CronJob, evaluate those two fields with OR logic once either one is restricted away from *. This tool matches that behavior on purpose.
Does it support @daily, @reboot, or other shortcut macros?
No, only the five standard numeric fields, since that's what most orchestrators require anyway. @daily maps to 0 0 * * *, @hourly to 0 * * * *, and @weekly to 0 0 * * 0.
Is my schedule sent to a server?
No. Parsing, the plain-English description, and the next-run calculation all run client side. Nothing about the fields you type is transmitted or stored.
Does the next-run calculation account for daylight saving time?
No, everything is computed in UTC, which has no DST. If the system running your cron daemon uses local time with DST, check the offset separately around the transition dates twice a year.
Can I type month or weekday names instead of numbers?
Yes. jan through dec and sun through sat work in the month and day-of-week fields alongside the numeric 1-12 and 0-6 ranges, including in ranges and lists.

The cron job fires. What gates the deploy it triggers?

upstreamapi ties feature-flag rollouts to an SLO budget, so a cron-triggered deploy can auto-rollback before the pager goes off, not after.

See how SLO-gated rollouts work Back to the generator