Cron Expression Generator

What Cron Expression Generator helps you do

Build and validate standard five-field cron schedules, start from useful presets, and preview the next five run times in your browser's local timezone. Matches common Linux cron — confirm against your scheduler's dialect before production. It is a quick way to catch a wrong field or a timezone assumption before a job silently runs at the wrong hour.

Schedule building and preview run entirely in your browser. No expression or schedule data is uploaded to Haivix.

How it works

Haivix validates each field's ranges, lists, steps, and wildcards, then evaluates upcoming runs using the browser clock and standard cron combination rules for day-of-month and day-of-week. When both date fields are restricted, common cron implementations match either field; when one is a wildcard, the restricted field controls the date.

How to use Cron Expression Generator

1. Start with a preset or edit minute, hour, day of month, month, and weekday fields directly.
2. Preview the expression to validate ranges and see the next five browser-local run times.
3. Copy the verified expression and confirm timezone and cron variant on your deployment platform.
4. Test the job in staging and compare the first run with the intended time.

When to use it

• Drafting backup, report, or cleanup schedules before pasting into CI or cron
• Explaining a five-field schedule during code review
• Checking whether a weekday + day-of-month restriction behaves as you expect
• Converting a human description such as every 15 minutes into cron syntax
• Reviewing a schedule that appears to run at the wrong hour
• Documenting a job's intended cadence next to its expression

When not to use it

• Schedulers that require seconds or year fields (AWS EventBridge, some Quartz configs)
• Guaranteeing DST behavior across all cloud schedulers without platform testing
• Sub-minute or complex holiday calendars
• Business-day schedules that skip holidays, which need a calendar-aware scheduler

Example

0 9 * * 1-5 runs at 09:00 on weekdays in the preview timezone — verify your server runs UTC while you preview local time. If the preview shows 09:00 local but the server is two hours ahead, the job will actually fire at 07:00 in your working day.

What you can do with Cron Expression Generator

• Build the five standard fields: minute, hour, day of month, month and weekday.
• Use wildcards, numbers, lists, ranges and step values in each field.
• Start from presets for common schedules.
• Validate field ranges and syntax before copying the expression.
• Preview the next five run times in the browser timezone.
• Copy the verified expression into a crontab or a deployment config.

Example: schedule a weekday report

Start from the weekday-at-nine preset, then adjust the hour and minute. Leave the day-of-month field as a wildcard so the weekday restriction controls the schedule rather than competing with it.

Preview the next runs and compare them with the timezone your server uses. If the preview is local and the server is UTC, convert the hour before saving the job.

Paste the expression into a staging environment and confirm the first two runs before promoting it to production. The preview shows intent; the scheduler is the final authority.

What to know before you start

• Five-field format only — no seconds or year field.
• Next-run preview uses your browser timezone, which may differ from the execution environment.
• Haivix documents common OR-style day matching; always verify with your scheduler docs.
• Holiday calendars and business-day rules are out of scope.
• The preview is a calculation, not a guarantee of a specific platform's behavior.

Common mistakes

• Assuming day-of-month AND day-of-week always intersect the way your platform documents
• Copying a preview time without converting from local browser time to server UTC
• Using step syntax unsupported by the target cron implementation
• Setting both day fields to a value and expecting both conditions to apply
• Forgetting that a five-field expression has no year field, so a one-off date needs a different tool
• Testing the expression only in the preview and never in the scheduler

Troubleshooting

If a field is rejected, check its range and separator. Minutes stop at 59, hours at 23, months at 12, and weekdays at 0 or 7 for Sunday depending on the implementation.

If the next-run preview looks shifted, compare the browser timezone with the server timezone. The preview is local by design.

If the job runs on the wrong days, check whether both day-of-month and day-of-week are restricted. Many cron implementations combine them with OR, not AND.

If a step expression is accepted here but rejected in production, the target scheduler may use a different dialect. Check its documentation before replacing the expression.

If the schedule seems to skip a run around a daylight-saving change, that is a timezone behavior, not necessarily a syntax error. Test the transition explicitly.