A cron job is a scheduled task that runs automatically at specified intervals on Unix/Linux systems. The schedule is defined using a cron expression — a string of 5 fields specifying minute, hour, day, month, and weekday.

What does * mean in a cron expression?

An asterisk (*) means 'every'. So * in the minute field means 'every minute', * in the hour field means 'every hour', and so on.

What does */5 mean in a cron expression?

The */n syntax means 'every n units'. So */5 in the minute field means 'every 5 minutes', */2 in the hour field means 'every 2 hours'.

Are cron jobs reliable for critical tasks?

Cron is reliable for most tasks, but does not have built-in retry logic or error alerting. For mission-critical scheduled tasks, consider dedicated job schedulers like Airflow, Temporal, or cloud provider equivalents like AWS EventBridge.

About Cron Job Generator

You are configuring a GitHub Actions workflow to run database backups every weekday at 3 AM UTC, and the last time you wrote a cron expression by memory you accidentally scheduled it for 3 AM on the 3rd of every month and a customer noticed before you did. Or a product manager asks for 'every other Monday and Wednesday between 9 and 5' and you need to verify whether that is even expressible in standard cron syntax before committing to the ticket. This generator accepts plain English ('every weekday at 9am', 'first of the month', 'every 15 minutes during business hours') and produces the five-field Unix cron expression, with a confidence indicator when the request is ambiguous. It also works in reverse: paste an expression and see the next five fire times in your local timezone plus a plain-English description. Preset buttons cover the common cases (hourly, daily, weekly, monthly) and the whole thing stays in the tab, so you can iterate on schedules for Vercel Cron, GitHub Actions, Kubernetes CronJob, systemd timers, or your Rails whenever gem without trial-and-erroring in production.

How it works

1
Natural-language parsing with confidence scoring
The NLP parser recognizes frequency patterns (every N minutes/hours, hourly, daily, weekly, monthly, yearly), weekday terms ('every weekday', 'Mon-Fri', 'weekends'), specific days ('Sunday and Wednesday'), time phrases ('at 3pm', 'at 14:30', 'midnight', 'noon'), and day-of-month ordinals ('the 15th of every month'). Confidence is 'high' for single-clause inputs and drops to 'medium' when we had to infer defaults (e.g. no time given for a monthly task defaults to midnight).
2
Next-fire calculation walks forward from now
For an expression like '0 2 * * 1-5', we iterate minute-by-minute forward from the current Date, checking each candidate against all five fields, and stop after finding the next five matches. This is correct but slow for sparse schedules (e.g. '0 0 29 2 *' finds Feb 29 leap years). The walk is capped at 10 years lookahead to prevent infinite loops on impossible expressions.
3
Reverse path converts expression to English
Each field is decoded independently: '*/5' becomes 'every 5', '1-5' becomes 'Mon-Fri', '0,12' becomes 'midnight and noon'. The phrases are composed by a small grammar that prefers natural forms ('every hour on weekdays') over literal ('minute 0 of every hour on days 1-5'). Non-standard entries like '@hourly' or AWS EventBridge's 6-field format with year are flagged with a warning since they will not work in standard cron daemons.

Pro tips

Cron runs in the daemon's timezone, not yours

Standard Unix cron uses the system timezone (check /etc/timezone or TZ env var). GitHub Actions and Vercel Cron both force UTC. Kubernetes CronJob lets you set spec.timeZone since 1.24 but old clusters ignore it. Always write your cron in the timezone of the daemon and comment the intended local time above the line. '0 13 * * *' in a UTC crontab is '9 AM Eastern' during DST and '8 AM Eastern' in winter — which is why database maintenance windows shift twice a year on servers nobody remembers to update.

Use */N with caution — it does not mean 'every N'

'*/15 * * * *' runs at minutes 0, 15, 30, 45 of every hour — not every 15 minutes from an arbitrary start. If a previous run stretches to 16 minutes, the next scheduled run at minute 30 will overlap or be skipped depending on your cron daemon's behavior. For truly-periodic 'N minutes after last completion' scheduling, use a job queue with a delay (BullMQ, sidekiq-scheduler, Temporal) rather than cron. This distinction matters for API rate-limit-sensitive jobs where overlapping runs can blow your quota.

Day-of-month and day-of-week are OR, not AND

The expression '0 0 15 * 1' fires at midnight on the 15th of any month AND on every Monday — not only on the 15th when it falls on a Monday. This is one of cron's most-copied bugs from Stack Overflow answers. If you need the AND semantics (fire only when day-of-month matches AND day-of-week matches), use '0 0 15 * *' and add an 'if [ $(date +%u) -eq 1 ]; then ... fi' guard inside the job script. Or switch to a scheduler like Temporal or Rundeck that supports richer recurrence semantics natively.

Honest limitations

· Standard five-field cron only — AWS EventBridge's six-field format (with year) and Quartz's seven-field format are not generated; the engines that read them have their own syntax.
· Special strings (@yearly, @monthly, @weekly, @daily, @hourly, @reboot) are not emitted but are accepted by most cron daemons as equivalents.
· Seconds-precision cron (as in Quartz or K8s with a 6-field extension) is not supported; the smallest unit is 1 minute as per standard Unix cron.

Frequently asked questions

Why is my cron expression not firing on GitHub Actions at the exact time I set?

GitHub explicitly documents that scheduled workflows can be delayed by up to 15 minutes during high-load periods, and they run in UTC. If you wrote '0 9 * * *' expecting 9 AM Eastern, the job fires at 9 AM UTC which is 4 or 5 AM Eastern depending on daylight saving. For time-critical schedules on GitHub, use 0 13 or 0 14 for 9 AM Eastern and add a comment explaining the DST gap. For sub-15-minute precision, use an external scheduler that hits a repository_dispatch webhook rather than relying on GitHub's built-in cron.

Can cron run a job every 30 seconds?

No. Standard Unix cron operates at minute granularity — the smallest interval is 1 minute, written as '* * * * *'. For sub-minute scheduling you have two options: run cron once a minute and have the script itself loop with a 30-second sleep between iterations (simple but drifts if the script ever exceeds 30s), or switch to a real scheduler like systemd.timer with OnCalendar=*:*:0/30, Temporal, or a simple Node/Go daemon with setInterval. Most systems that claim 'cron-like' scheduling at sub-minute intervals are using one of these alternatives internally.

How do I handle daylight saving time in cron?

There is no clean answer — standard cron does not know about timezones. Two practical approaches: (1) run your crond in UTC and translate mentally, accepting that the local-time firing will shift by an hour twice a year; (2) run in local time and accept that the '2:30 AM' slot fires twice on fall-back day and not at all on spring-forward day. For jobs that must fire exactly once per 24 hours regardless of DST, schedule for a time that is never in the DST gap (avoid 02:00-03:00 local) and use a job queue's deduplication instead of relying on cron correctness.

What is the difference between '0 */2 * * *' and '0 0,2,4,6,8,10,12,14,16,18,20,22 * * *'?

Semantically nothing — both fire at minute 0 of every even hour. The shorter form is easier to write and read, but the expanded form makes it obvious exactly which hours fire, which matters for code review. There is one subtle case: '*/N' when N does not divide 60 evenly can produce unexpected gaps. '*/13 * * * *' fires at minutes 0, 13, 26, 39, 52 within each hour, then jumps to 0 of the next hour — not minute 5 as you might expect — so the gap between minute 52 and the next minute 0 is only 8 minutes, not 13.

Does this generator support the L and W special characters from Quartz?

No. L (last day of month) and W (nearest weekday to a given day) are Quartz cron extensions used by Java schedulers like Spring's @Scheduled, Elastic's Watcher, and some Oracle products. Standard Unix cron, GitHub Actions, Vercel Cron, and Kubernetes CronJob all reject those characters. If you need 'last day of the month' on a Unix system, use the workaround '0 0 28-31 * *' combined with an in-script check like 'if [ $(date -d tomorrow +%d) -eq 1 ]; then run; fi' — cron fires every day from 28 through 31, and the script itself decides whether today is actually the last day.

Cron jobs rarely stand alone — they usually invoke a script that calls an API with JSON payloads, authenticates with a signed token, and logs structured output. The json-formatter helps you validate the payload your scheduled job posts before the first real run fires. The jwt-decoder lets you inspect the bearer token your cron uses for auth, especially useful when the token is set to expire daily and you are debugging why the 2 AM job fails every day. And when your cron script needs to generate a random secret for each run (e.g. rotating API keys), the password-generator's crypto-grade output plugs in as a one-liner.