Cron builder, explainer, next-run preview and platform checker
Once fat-fingered a cron line. Backup fired every minute instead of once a night. Filled the disk by breakfast. So I keep this around now. Paste an expression (five fields, or six if you need seconds) and I’ll expand every field, say in plain English what it does, then show you the actual next dozen run times. Load a common schedule. Check how your platform reads it. Catch the dumb mistakes here, where it’s free, instead of on a live server or in some container behind an uptime monitor.
Heads up. The preview does the math in your browser and shows it in whatever timezone you pick here. Your real job runs in whatever timezone the scheduler on the box is set to. Those two don’t have to agree. That gap is where people get burned.
Cron expressions are small strings with large consequences
One short line kicks off your backups. Your reports, your cleanup jobs, the queue workers, the deploys, all of it leaning on five tiny fields. The syntax is dense enough that a typo just hides in plain sight. The server’s timezone might not be the one in your head. Day-of-month and day-of-week don’t combine the way most people assume they do. And some platforms bolt on a seconds field that classic Unix cron has never heard of. I once watched a schedule that “looked fine” go off a few hundred times more than anyone wanted. Nobody enjoyed that morning.
I built this to be the sanity check I run before I trust a schedule. It breaks each field down. It says out loud what the job will actually do, lines up the next runs, and flags where a given platform might read your syntax differently. Plain five-field cron, the six-field version with seconds, it handles both. And it’ll wave at the usual traps before you paste anything into a server, a Docker container, a Kubernetes CronJob, a GitHub workflow or whatever automation tool you’re feeding that day.
How to read a cron schedule
Read it left to right: minute, hour, day of month, month, day of week. Six fields? Then seconds sneak in at the front. A star means “every value allowed here.” Commas list a few specific values. A dash is a range. A slash is a step. Honestly, the symbols aren’t the hard part, you’ll have them down in an afternoon. What bites you is making sure the expression means the same thing to the scheduler that’s actually going to run it.
- Five-field cron is the shape you’ll meet most on Unix: minute hour day month weekday.
- Six-field cron just tucks seconds in front of the minutes.
- Quartz syntax throws in extra tokens like
?,L,Wor#that plain cron has never had. - Timezone lives with the scheduler on most systems, not inside the string. Don’t assume the expression carries it, because it usually doesn’t.
- Next run preview is, honestly, the fastest way to spot a schedule that’s quietly wrong before it ships.
Common cron debugging examples
Job fired at the wrong hour? Don’t touch the expression yet. Check the scheduler’s timezone first, because most of the time that’s the culprit. Running way too often? Look at your step fields, the */5 kind. Platform spitting the expression back at you? Work out whether it wants five fields, six, or full Quartz. And if you’ve pinned both day-of-month and day-of-week, go find out whether your scheduler reads that as OR or as a strict AND. That one difference has eaten more than one of my weekends.
Common questions
Does every cron system support seconds?
Nope. This one trips people up constantly. Classic Unix cron stops at five fields. No seconds, full stop. Some newer schedulers do add a seconds field, and Quartz-style systems pile on even more syntax on top. So before you write that six-field line, make sure the thing running it actually speaks six fields.
What timezone does cron use?
Whatever timezone the server or scheduler is set to. Not the one on your laptop. Usually not UTC either, unless somebody made it so. A handful of hosted platforms let you set a per-job timezone, which is lovely when you’ve got it and a sharp edge the day you forget you don’t. When in doubt, log the date right at the top of the job and read it back.
Can this preview replace production testing?
No, and I’d hate for you to think it does. It catches the obvious blunders fast. But the real source of truth is the scheduler that actually runs your job, full stop. Use this to weed out the silly stuff, then go confirm against the live system before you call it done.
What do the five cron fields mean?
Left to right: minute, hour, day of month, month, day of week. Drop an asterisk in any of them and you’re saying “every value here.” So a star in the minute field means every single minute. Once that order is muscle memory, reading a cron line stops being intimidating.
What is the difference between */5 and 5 in a cron field?
Easy to mix up. Wildly different results. */5 is a step, every fifth unit, so in the minute field that’s 0, 5, 10, 15 and on through the hour. Plain 5 is a single value: it fires once, at exactly 5. So one runs twelve times an hour. The other runs once. Reach for the wrong one and your “occasional” job suddenly isn’t occasional.
How do I run a job every day at midnight?
0 0 * * * does it. Minute 0 of hour 0, every day. Paste it up top and I’ll spell it out, then show you the next few midnights it’ll actually hit. That way you know it’s landing where you think before it goes anywhere near live.
