Cron Expression Builder & Validator

Great question — this trips up a lot of folks. Standard Unix cron has 5 fields (minute, hour, day, month, weekday), but you'll sometimes see 6-field versions. In Quartz scheduler (Java), Spring's @Scheduled, and a few other engines, the 6th field is actually seconds, placed at the start. In other flavours like the year-extended cron, the 6th (or 7th) field is the year. So before you paste an expression anywhere, always check which engine you're targeting — Linux crontab, Quartz, and AWS EventBridge each have slightly different rules.

Easy one — just list both hours in the hour field. Use 30 6,18 * * * and you're done. The comma lets cron run at multiple specific values, so 6 and 18 in the hour slot translate to 6:30 AM and 6:30 PM in 24-hour time. Don't write two separate cron lines unless you genuinely need different commands at each time. Always remember cron uses the server's local timezone, so if your server is on UTC and you want IST, adjust the hours or set a TZ variable in the crontab.

I see this all the time. Usual suspects: timezone mismatch (server in UTC but you're thinking IST), wrong user (root's crontab vs your user's crontab), broken PATH so the command can't find binaries, or a missing newline at the end of the crontab file. Check /var/log/syslog or /var/log/cron for entries. Run crontab -l to confirm your job is actually saved. If the script works manually but not via cron, it's almost always an environment issue — wrap the command with full paths and explicit env variables.

For an annual job, pick a specific date and time. For example, 0 0 1 1 * runs at midnight on January 1st every year. The shorthand @yearly (or @annually) does the same thing if your cron daemon supports it — vixie-cron and most modern Linux versions do. If your business calendar starts in April (Indian financial year), use 0 0 1 4 * instead. Just remember that if the server is down on that exact minute, the job is missed entirely — anacron or systemd timers handle that gap better than plain cron.

The */5 is a step value — it means "every 5 units of whatever field it's in." Put it in the minute field (*/5 * * * *) and your job runs every 5 minutes: at :00, :05, :10, :15, and so on. In the hour field, it means every 5 hours. It's just shorthand for 0,5,10,15,20,25,30,35,40,45,50,55. Super handy for monitoring scripts or cache refreshes. One catch: it always starts counting from 0, not from when you save the crontab, so it's not drift-free.

Yes, most modern cron implementations support three-letter day names: SUN, MON, TUE, WED, THU, FRI, SAT. So 0 9 * * MON-FRI runs at 9 AM every weekday — perfect for office-hours alerts. Same goes for month names (JAN-DEC). They're case-insensitive. Older cron versions (some BusyBox builds, old Solaris) only accept numbers (0-6 or 1-7, where Sunday is 0 or 7). If portability matters, stick to numeric values. Quartz and AWS EventBridge also accept names but sometimes use slightly different conventions, so always test the expression before deploying.

Standard Unix cron's smallest unit is one minute, so the highest frequency is once per minute (* * * * *). If you genuinely need sub-minute scheduling, cron isn't the right tool — use systemd timers (which support OnUnitActiveSec=30s), Quartz with seconds field, or a small loop with sleep. For high-frequency jobs, also consider an event-driven queue like Redis with Sidekiq, or a long-running daemon. Hammering cron every minute with overlapping jobs piles up load fast, so add a lock file (flock /tmp/job.lock) to prevent concurrent runs from stepping on each other.

That's exactly what our Cron Expression Builder shows you on the right side of the page — paste your expression and you get the next several scheduled run times instantly, in your local timezone. Programmatically, the easiest options are the croniter Python library, cron-parser in Node.js, or Quartz's CronTrigger.getNextFireTime() in Java. CLI fans can use cronnext on Linux. Always preview before you deploy — it catches off-by-one mistakes (like accidentally scheduling for the 31st of February, which never fires) before they ever hit production.

Position matters! 0 * * * * means "minute 0 of every hour" — so it fires at 1:00, 2:00, 3:00, etc., 24 times a day. Whereas * 0 * * * means "every minute during hour 0" — that's every minute between midnight and 12:59 AM, so 60 fires bunched at the start of the day. Big difference. The first is great for hourly reports; the second is almost never what you actually want. When in doubt, plug it into a preview tool to see the next run times.