Cron Expression Generator & Explainer

A cron expression is essentially a compact scheduling language that tells a computer exactly when to wake up and do something. Every Unix-like server, cloud platform, and countless automation tools speak this language. The expression itself is just five tokens separated by spaces, but those five tokens can describe schedules ranging from "every single minute" to "only at 3:15 PM on the third Wednesday of March."

This tool works in both directions. You can build an expression visually by selecting your desired schedule, and the tool writes the cryptic string for you. Or you can paste in an existing expression you found in someone else's code, and the tool will translate it into plain English. Either way, you also get the next five scheduled run times calculated instantly, so you can verify the expression actually does what you think it does. That verification step matters more than most people realize until they've been burned by a misconfigured backup job that ran daily instead of weekly.

Every standard cron expression follows the same structure: minute, hour, day-of-month, month, day-of-week. Think of it as answering five questions in order. At what minute? Which hour? What day of the month? Which month? What day of the week? The expression 30 14 1 * * answers these as: minute 30, hour 14 (2 PM), day 1, every month, any weekday. That runs at 2:30 PM on the first of every month.

Special characters expand your options beyond single values. An asterisk means "every possible value." A slash creates intervals, so */15 in the minute field means every 15 minutes: 0, 15, 30, 45. A hyphen defines ranges, so 1-5 in the weekday field means Monday through Friday. A comma lets you list specific values, so 0,30 in the minute field means only at minute 0 and minute 30. Combining these, the expression 0 9-17 * * 1-5 runs every hour on the hour from 9 AM to 5 PM, Monday through Friday. That's nine executions per workday, zero on weekends.

Suppose you need to back up a production database every night at 2:30 AM, and every Sunday at 4 AM for a full weekly backup. Start with the nightly job. You want minute 30, hour 2, every day of the month, every month, every day of the week. Enter those values in the visual builder or type 30 2 * * * directly. The tool confirms: "At 2:30 AM every day" and shows the next five run times, like tomorrow at 2:30 AM, then the day after, and so on.

For the weekly full backup, you need minute 0, hour 4, any day of the month, any month, but only Sunday (day 0 in most systems). The expression becomes 0 4 * * 0, and the tool translates it as "At 4:00 AM every Sunday." If your server uses 7 for Sunday instead of 0, the tool's cheat sheet clarifies that both work. Now you have two cron entries ready to paste into your crontab or CI/CD configuration, each verified before they touch production.

Most people use cron for daily or hourly jobs, but it handles less obvious patterns too. Need a quarterly report on the first day of January, April, July, and October at 6 AM? The expression 0 6 1 1,4,7,10 * does exactly that. The month field accepts comma-separated values, so you specify only those four months. The tool shows your next run as January 1st at 6 AM, then April 1st, confirming the three-month gap.

Another overlooked use is business-hour alerting. Say you want uptime checks every 10 minutes, but only during business hours and only on weekdays to avoid weekend noise. The expression */10 9-17 * * 1-5 runs at minutes 0, 10, 20, 30, 40, and 50 during each hour from 9 AM through 5 PM, Monday to Friday. That's 54 checks per workday and exactly zero on Saturday or Sunday. Paste that into the explainer, and you'll see every scheduled time laid out clearly before you commit it to your monitoring system.

The single most confusing behavior in cron involves setting both day-of-month and day-of-week to specific values. If you write 0 9 15 * 1 hoping it means "9 AM on the 15th, but only if it's a Monday," you'll be disappointed. Most cron implementations treat this as OR logic: it fires on every 15th and every Monday. To run only when both conditions are true, you need wrapper logic outside cron or a scheduling tool that supports AND logic explicitly.

Another common mistake is forgetting that hour uses 24-hour format. Writing 0 9 * * * runs at 9 AM, not 9 PM. For evening schedules, you need 0 21 * * * for 9 PM. Time zones also trip people up because cron typically uses the server's local time, not UTC, unless configured otherwise. Always check your server's time zone setting before deploying a schedule, especially for servers running in cloud regions far from your office. The tool shows run times in your browser's local time, so compare carefully if your server differs.