Cron Expression Builder & Tester

Cron expressions look intimidating because they pack five different scheduling concepts into five whitespace-separated fields with no labels. Once you internalize the order — minute, hour, day-of-month, month, day-of-week — they become legible at a glance. The cheatsheet: * means "every value", 5 means "exactly 5", 1-5 means "1 through 5 inclusive", 1,3,5 is a list, and */15 is "every 15 starting from 0".

The minute field is where most production cron jobs go wrong. People write * * * * * for "hourly" and wonder why their database is on fire — that's every minute. The fix is to anchor to 0: 0 * * * * means "at minute zero of every hour" — that is, hourly.

The day-of-week field is the other landmine. POSIX cron treats day-of-month and day-of-week as an OR condition when both are specified. So 0 0 15 * MON fires on the 15th of every month and every Monday — not "the 15th if it's a Monday". If you need that, do the filtering inside the job, not in the cron line.

Timezones are the silent killer. By default, cron runs in the server's local time — which is almost always UTC in cloud environments. A line that reads 0 9 * * * fires at 9 AM UTC, which is 4 AM Eastern in winter and 5 AM Eastern in summer. Either set the TZ environment variable explicitly in your crontab (or DAG, or Kubernetes manifest), or do the math and write your expression in UTC. We've audited dozens of incident postmortems where the root cause was "the daily report ran 5 hours later than the team thought."

Step values are subtler than they look. */15 * * * * means "every 15 minutes starting at minute 0" — so :00, :15, :30, :45. But 5/15 * * * * means "starting at minute 5, every 15 minutes" — :05, :20, :35, :50. Useful if you have multiple servers and want to stagger their cron jobs to avoid the thundering-herd problem at exact zero.

Year field exists in some implementations but not POSIX. AWS EventBridge accepts a sixth field (year). Quartz, used by Java schedulers, accepts seconds (so a 6-field expression in Quartz is second minute hour day month dow). Kubernetes CronJob, GitHub Actions schedule, GitLab CI schedule, and standard Unix cron all use the 5-field POSIX format that this builder generates.

When NOT to use cron. Cron is a time-based trigger — it has no idea whether your previous run finished, whether the queue is backed up, or whether your dependencies are healthy. For anything that absolutely cannot run twice in parallel, or cannot run if the previous run failed, you want a queue worker with distributed locking — not cron. A common pattern: cron fires every 5 minutes, the job acquires a Redis lock, and skips if another instance is already running. This is also why we usually deploy API-driven background workers instead of crontab for production SaaS.

Need help architecting a scheduled job system that won't bite you at 3 AM? See our services overview or book a 20-minute architecture call.