⏰ Cron Expression Builder

Last updated: June 18, 2026

⏰ Cron Expression Builder

Build cron schedules visually, decode any expression, and preview the next run times.

Every minute
0–59
0–23
1–31
1–12
0–6 (Sun=0)

What Even Is a Cron Expression, and Why Should You Care?

Imagine you want your server to send out a daily email digest at 7 AM, clean up old log files every Sunday night, or back up a database every four hours. You could write a script and sit there manually triggering it — but that's obviously not how anyone actually runs software. What you want is a scheduler that fires your code automatically on a precise, repeating schedule. That's exactly what cron does, and cron expressions are how you tell it when.

Cron itself has been around since the 1970s on Unix systems. The name comes from the Greek word "chronos" (time), and the utility has aged remarkably well. Today you'll find cron-style scheduling in Linux servers, GitHub Actions, AWS Lambda, Kubernetes CronJobs, Vercel, Netlify, and just about every cloud platform in existence. Learning to read and write cron expressions is one of those foundational skills that keeps paying off no matter what stack you're on.

The Five-Field Format, Decoded

A standard cron expression has exactly five space-separated fields. Reading left to right:

┌──────────── minute (0–59)
│  ┌─────────── hour (0–23)
│  │  ┌──────────── day of month (1–31)
│  │  │  ┌─────────── month (1–12)
│  │  │  │  ┌──────────── day of week (0–6, Sunday = 0)
│  │  │  │  │
*  *  *  *  *

Each field can hold a plain number, a wildcard * (meaning "any value"), a range like 1-5, a comma-separated list like 1,3,5, or a step like */15 (meaning "every 15 units"). Combinations work too — 0,30 in the minute field means "at zero minutes and thirty minutes past the hour."

Reading Real Examples Without Breaking a Sweat

Let's go through a handful of expressions you'll encounter constantly in the wild:

0 0 * * * — The minute is 0, the hour is 0, everything else is a wildcard. This runs once a day at exactly midnight. Perfect for nightly cleanup jobs.

*/5 * * * * — The step syntax in the minute field: every 5 minutes, all day, every day. You'd use this for things like checking an API endpoint or updating a live dashboard.

0 9 * * 1-5 — 9 AM, Monday through Friday. The 1-5 in the day-of-week field covers Monday (1) to Friday (5). Great for business-hours-only notifications.

0 0 1 * * — Midnight on the first day of every month. This is a classic for generating monthly reports or resetting usage counters.

30 6 * * 0 — 6:30 AM every Sunday. That day-of-week value of 0 is Sunday. Some systems also accept 7 as Sunday, which trips people up the first time they see it.

The Tricky Bits That Catch People Off Guard

Hour values are in 24-hour format — there's no AM/PM in cron. So if you want something at 3 PM, you write 15 in the hour field, not 3. Forgetting this is probably the most common cron mistake, especially coming from environments where 12-hour time is the default.

The day-of-week and day-of-month fields have an interesting quirk when both are set to something other than *. Most cron implementations treat this as an OR rather than an AND — so 0 0 1 * 0 runs at midnight on the 1st of the month and also at midnight every Sunday. Not both conditions together — either one triggers the job. This surprises a lot of developers who assume it means "Sunday the 1st" only.

Time zones are another landmine. Cron on your server runs in whatever timezone that server is configured for — usually UTC, but not always. If you set a job for 0 8 * * * expecting it to fire at 8 AM your local time, but your server is in UTC+0 and you're in UTC+5:30, it'll actually run at 1:30 PM your time. Always check your server's timezone with timedatectl or date before deploying scheduled jobs.

Step Values Are More Powerful Than They Look

The slash syntax deserves its own moment. */10 in the minute field means "start at 0, then add 10, then 20, then 30, then 40, then 50 — all within each hour." But you can also combine it with a starting point: 15/10 means "start at minute 15, then 25, 35, 45, 55." The format is start/step, and it gives you much more granular control than listing individual values.

Similarly, 8-17/2 in the hour field means "every 2 hours, but only between 8 AM and 5 PM." That's how you build schedules that only fire during business hours without listing out every single hour individually.

How to Actually Verify a Cron Expression Before It Bites You

The danger with cron is that a typo doesn't fail loudly — it just silently runs at the wrong time, or never runs at all. There are two good habits that will save you grief.

First, always preview the next several scheduled run times before deploying. If you expected your job to run twice a day and the preview shows it running every two minutes, you've caught the mistake before it causes problems. A tool that shows you the actual datetime stamps for the next 10 runs makes this immediate and visual.

Second, check your system logs after deployment. On Linux, cron logs to /var/log/syslog or /var/log/cron depending on the distribution. A line like CRON[1234]: (root) CMD (/path/to/script.sh) tells you the job fired. If you don't see it when expected, either the expression is wrong or the cron daemon isn't running.

Cron Beyond the Command Line

Once you understand the basic five-field format, you'll recognize it everywhere. GitHub Actions workflows use a schedule key with cron syntax. Kubernetes CronJobs have a schedule field that accepts the same expressions. AWS EventBridge (formerly CloudWatch Events) has a slightly extended cron syntax with a sixth field for years, but the core five fields work the same way.

Many application frameworks have built-in cron-style schedulers too — Laravel's task scheduler, Node's node-cron package, Python's APScheduler — and they all use variations of the same expression format. Understanding the fundamentals transfers across all of them.

The visual builder here takes care of the syntax so you can focus on the logic: pick what you need from the dropdowns and quick-select buttons, watch the expression and its human-readable description update in real time, then hit "Build & Preview" to see exactly when your job will fire next. No more guessing, no more miscounted fields.

FAQ

What does the asterisk (*) mean in a cron expression?
An asterisk is a wildcard that means 'every possible value' for that field. So * in the hour field means 'every hour,' * in the day-of-week field means 'every day of the week,' and so on. When all five fields are *, the job runs every minute.
How do I run a cron job every 30 minutes?
Use */30 in the minute field and * in all other fields: */30 * * * *. This fires at minute 0 and minute 30 of every hour. Alternatively, 0,30 * * * * does exactly the same thing by explicitly listing both minutes.
Why is my cron job running at the wrong time?
The most common reason is a timezone mismatch — cron runs in the server's local timezone, which is often UTC. Check your server time with the 'date' command. Also remember that cron hours use 24-hour format, so 3 PM is hour 15, not hour 3.
What is the difference between day-of-month and day-of-week in a cron expression?
Day-of-month (field 3) specifies the numeric date, like the 1st or the 15th. Day-of-week (field 5) specifies which day of the week, from 0 (Sunday) to 6 (Saturday). When you set both fields to specific values instead of *, most cron implementations run the job when EITHER condition is true, not when both are true simultaneously.
Can I run a cron job only on weekdays?
Yes. Use 1-5 in the day-of-week field (Monday through Friday). For example, 0 9 * * 1-5 runs at 9 AM every weekday. If you also want to exclude holidays, you'd need application-level logic since cron doesn't have a concept of public holidays.
How many fields does a cron expression have, and what order are they in?
Standard cron has 5 fields in this order: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6). Some extended formats like AWS EventBridge add a 6th field for year, but the classic Unix cron and most tools use just the five.