Cron Expression Generator
Build and validate cron expressions with a human-readable description and the next run times — entirely in your browser.
- Runs in your browser
- No upload, no tracking
- Free forever
Presets
e.g. */5
e.g. 9
e.g. 1
e.g. */2
e.g. 1-5
Editing updates the builder above. Press Enter to apply.
Expression
* * * * *AWS EventBridge
cron(* * * * * *)Spring @Scheduled
0 * * * * *How it works
A cron expression generator turns a schedule into the five-field crontab syntax (minute, hour, day-of-month, month, day-of-week) that Unix cron, Kubernetes CronJobs and most schedulers understand — and reads it back to you in plain English with the next run times. This tool runs entirely client-side, so nothing about your schedule is uploaded. It is built by JusDB, a managed database operations team that schedules backups, vacuums and maintenance jobs with cron every day.
- 1
Start from a preset
Pick a preset like Every 5 min, Weekdays 9am or Monthly 1st to drop a ready-made expression into the builder, then tweak it.
- 2
Edit any field
Use the five-field builder or type a raw expression — each supports *, ranges (1-5), lists (1,3,5) and steps (*/15). The builder and raw box stay in sync as you edit either one.
- 3
Read it back
Every valid expression gets a plain-English description plus the next 5 execution times in UTC, so you can confirm the schedule before shipping it.
- 4
Convert and copy
Copy the cron string, or grab the equivalent AWS EventBridge cron(...) and Spring @Scheduled six-field expressions for your config.
Frequently asked questions
- What cron format does this use?
- The standard 5-field Unix cron format: minute, hour, day of month, month, and day of week. The builder and the raw expression stay in sync as you edit either one.
- Does it show when my schedule will run?
- Yes. For any valid expression it shows a plain-English description plus the next 5 execution times in UTC, so you can confirm the schedule does what you expect.
- Can it convert to other schedulers?
- Yes. It outputs the equivalent AWS EventBridge cron(...) syntax and a Spring @Scheduled 6-field expression, ready to copy into your config.
- Does it support steps, ranges and lists?
- Yes. Each field accepts *, single values, ranges like 1-5, lists like 1,3,5 and steps like */15, and every field is validated against its allowed range.
- Why are the next run times in UTC?
- Standard cron has no timezone, and most servers and schedulers evaluate cron in UTC, so the next 5 executions are shown in UTC to match production behaviour. Offset them to your local zone when you read them.
- Is my cron expression sent anywhere?
- No. Parsing, validation, the plain-English description and the next-run calculation all run locally in your browser. Nothing is uploaded to JusDB or any server.
Understanding cron expressions in depth
A cron expression is five space-separated fields read left to right: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12), and day-of-week (0–6, where 0 is Sunday). The scheduler fires a job at every moment that matches all five fields, so reading an expression well is mostly about reading those fields together rather than one at a time.
The special characters that do the work
Five characters carry most of the meaning. An asterisk * means “every value” for that field. A comma builds a list (1,15,30), a hyphen builds an inclusive range (9-17), and a slash adds a step (*/15 is every 15 units, 10-50/10 is every tenth value within a range).
Because steps and ranges compose, 0 9-17/2 * * 1-5 reads as “at minute 0, every second hour from 9 to 17, Monday through Friday.” Building expressions from these primitives is far less error-prone than memorising whole strings.
Gotchas that bite in production
The most surprising rule is that when both day-of-month and day-of-week are restricted (neither is *), cron treats them as OR, not AND. So 0 0 1 * 1 runs on the 1st of the month and every Monday, not only on a Monday that falls on the 1st. Leave one field as * whenever you want predictable behaviour.
Standard cron has no timezone: most daemons evaluate in the server’s local time or UTC, and during a daylight-saving transition a job scheduled for the skipped hour may be missed or run twice. Cron also never waits for the previous run to finish, so a long job can overlap itself unless you add a lock. And watch the field count — classic Unix cron uses five fields, while Quartz and Spring @Scheduled use six or seven (adding seconds and an optional year), so the same string means different things in different systems.
Cron in the database world
Schedules drive a lot of routine database operations. On PostgreSQL, the pg_cron extension stores cron expressions in a catalog table and runs SQL on schedule from inside the database — ideal for a nightly VACUUM, a periodic REFRESH MATERIALIZED VIEW, or pruning old partitions. MySQL offers the same idea through the Event Scheduler with CREATE EVENT ... ON SCHEDULE, and operators commonly wire OS-level cron to trigger logical backups (pg_dump, mysqldump) or snapshot rotation.
For these jobs the next-run preview matters: a backup that quietly fires at the wrong hour, or an analytics rebuild that overlaps peak traffic, is the kind of bug that only shows up days later. Confirm the timing before you ship.
Since standard cron is timezone-naive, sanity-check the next run times against your own zone with the timestamp converter before deploying a schedule.