SimpleCronTab

What is a cron expression?

A cron expression is a short, five-field string that tells a scheduler when to run a job. The five fields, in order, are minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, with Sunday as 0). Each field accepts a number, a list (1,15,30), a range (9-17), a step (*/5), or the wildcard *. The expression 0 9 * * 1-5, for example, fires at 09:00 every weekday — the minute is fixed at 0, the hour at 9, the day-of-week constrained to Monday through Friday, and the other two fields left wild.

Why a visual cron builder?

Writing cron by hand is a deceptively error-prone task. The most common mistakes are mechanical: an off-by-one in the day-of-week field (Sunday is 0 in Unix cron but 1 in Quartz), or an inverted interpretation of the day-of-month and day-of-week fields, which join with OR rather than AND when both are restricted. Step values that do not divide the field range evenly — */7 in the minute field, for instance — produce uneven gaps at the hour boundary because cron resets the step on each field rollover. Building the expression by clicking on minute, hour, and weekday selectors sidesteps all three traps: the editor only generates legal expressions, and the next-execution preview makes a misconfigured weekday obvious before the schedule reaches production.

What you can do with this tool

• Build visually. Click to select minutes, hours, days, months, and weekdays; the expression updates live.
• Preview executions. See the next ten fire times on a calendar or timeline, in any IANA timezone.
• Compare expressions. Paste two or three schedules side-by-side and diff their upcoming fires — useful when migrating from one cadence to another.
• Convert formats. Translate between standard 5-field Unix cron, Quartz (with seconds and optional year), AWS EventBridge, Vercel, and GitHub Actions dialects.
• Use the free API. Programmatically parse, validate, humanise, and compute next executions via the REST endpoints documented at /api-docs.

Common cron schedules

A handful of cadences cover the vast majority of real production schedules. Polling jobs — replica lag monitors, queue-depth checks, webhook retry sweeps — typically run every 5 minutes, which is also the minimum interval GitHub Actions guarantees. Aggregation and rollup work that does not need sub-hour resolution runs every hour on the top of the hour. Daily reporting, backups, and clean-up jobs usually fire at midnight when the host is idle. Operational tasks that should only run during business hours — for example invoice generation or staffing emails — fire on weekdays at 9 AM in the relevant local timezone. Weekly rollups run on Mondays; monthly billing tasks fire on the first of the month. The examples index organises all 204 covered cadences by category.

Where this tool fits

Cron is not a single thing. Linux crond, Quartz Scheduler, AWS EventBridge, Vercel Cron Jobs, GitHub Actions on.schedule, Kubernetes CronJob resources, and framework schedulers in Laravel, Rails, Spring Boot, and Django all accept cron syntax — but each adds quirks. Quartz takes six fields with a seconds column first. AWS uses ? instead of * when either the day-of-month or day-of-week is restricted. GitHub Actions caps the cadence at five minutes and may silently delay during peak load. The platform-specific setup guides at Laravel, Spring Boot, AWS Lambda, and GitHub Actions walk through the minimum syntax each platform accepts and the gotchas to expect.