Crontab Generator

Cron is the Unix job scheduler. Born at Bell Labs in the late 1970s, it has outlived almost every contemporary technology: in 2026 every Linux server, every macOS install, every Docker base image, every Kubernetes CronJob resource, and every CI provider on earth speaks some flavour of the same five-field cron syntax. Five fields, separated by spaces, in this fixed order: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12), day-of-week (0–6, where 0 is Sunday). Each field is either a specific value, a list (1,15,30), a range (9-17), a step (*/15), or the wildcard * meaning "every".

The timezone trap

The single most-common cron bug in production is a timezone mismatch. Cron evaluates every expression in the timezone of the process that runs it. On most cloud VMs — AWS EC2, GCP Compute, DigitalOcean, AlibabaCloud, even Azure — the default OS timezone is UTC, not the local timezone of the team operating the server. A Singapore-based ops team writing 0 9 * * 1 ("Monday at 9am") on a UTC server will see the job fire at 5pm Singapore time, not 9am. The fix is either to set the server's TZ environment variable, change the system timezone, or — better — write your cron in UTC and document the local equivalent in a comment. The tool above shows the next five runs in your browser's local timezone so you can sanity-check this immediately.

Special strings and platform variants

Most cron implementations accept seven shorthand strings: @yearly (or @annually), @monthly, @weekly, @daily (or @midnight), @hourly, and @reboot. They map to the obvious equivalents (@hourly = 0 * * * *) except @reboot, which runs once when the cron daemon starts. Quartz (the Java/Jenkins scheduler) uses a six-field syntax with seconds as the leading column — most other systems would interpret a quartz expression incorrectly. AWS EventBridge uses six fields too but with year as an extra trailing column. The tool here is the classic Vixie 5-field cron used by Linux, macOS, and every shell-based scheduler.

Step syntax and the */15 trap

The step expression */15 in the minute field means "every 15 minutes starting from minute 0" — so it fires at :00, :15, :30, :45. It is not equivalent to "every 15 minutes from when I deploy" — cron has no concept of a relative start time, only absolute clock minutes. Step expressions can also work on ranges: 9-17/2 in the hour field means "every 2 hours from 9 to 17" — firing at 09, 11, 13, 15, 17. The 0,15,30,45 * * * * long form is identical to */15 * * * * but more verbose; pick whichever your team reads more easily.

GitHub Actions and the schedule-event quirks

GitHub Actions' on.schedule uses standard 5-field cron syntax but evaluates in UTC only — no per-workflow timezone override. The minimum interval GitHub will reliably honour is 5 minutes; if you write * * * * * ("every minute") your workflow will often skip runs under load. Also, scheduled workflows on default branches without recent activity (no pushes in 60 days) are disabled automatically — a common reason "my scheduled GitHub Action stopped firing." For genuinely time-critical jobs, run cron on a dedicated VM, not in a CI scheduler.

Validating your expression before you ship

Three quick checks save most production cron incidents. First: paste the expression into the tool above and read the next 5 runs out loud — if the times don't match your mental model, the expression is wrong. Second: double-check what timezone the executing host is in (date on Linux, cluster.timezone on Kubernetes, the function settings on AWS Lambda or Cloudflare Workers). Third: if your job mutates anything irreversible, add an early-exit guard inside the script that re-checks today's date — belt and braces beats a 3 AM page.