Cron Expression Generator

What is a cron expression?

A cron expression is a compact string of five space-separated fields that defines a recurring schedule. Originally from Unix's cron daemon, the format is now used universally in task schedulers, CI/CD pipelines, cloud functions (AWS Lambda, Azure Functions, Google Cloud Scheduler), and container orchestration systems (Kubernetes CronJobs). Each field specifies a time component, and together they define exactly when a job should run.

The five fields explained

Reading left to right, the fields represent:

• Minute (0–59) — which minute of the hour to run
• Hour (0–23) — which hour of the day (24-hour clock, UTC unless configured otherwise)
• Day of month (1–31) — which calendar day to run
• Month (1–12 or JAN–DEC) — which months to run
• Day of week (0–7 or SUN–SAT, where both 0 and 7 represent Sunday) — which days of the week to run

Special characters

• * (asterisk) — every possible value for that field, e.g. * in the minute field means every minute
• , (comma) — list of values, e.g. 1,15,30 in the minute field runs at minutes 1, 15, and 30
• - (hyphen) — range of values, e.g. 9-17 in the hour field means every hour from 9 AM to 5 PM
• / (slash) — step values, e.g. */15 in the minute field means every 15 minutes

Common schedule examples

• * * * * * — every minute
• 0 * * * * — every hour on the hour
• 0 0 * * * — midnight every day
• 0 9 * * 1-5 — 9 AM on weekdays (Monday–Friday)
• 0 0 * * 0 — midnight every Sunday
• 0 0 1 * * — midnight on the first day of every month
• */15 * * * * — every 15 minutes
• 0 2 * * 6 — 2 AM every Saturday

How the explanation is generated

Clicking Explain sends your expression to the server, where it's parsed and translated by the CronExpressionDescriptor library — not a template that echoes your input back. Two real examples: */15 * * * * translates to "Every 15 minutes", and 0 9 * * 1-5 becomes "At 09:00 AM, Monday through Friday" — actual phrasing, not a paraphrase. Each of the five fields is also range-checked before translation, so something like 99 in the minute field (minutes only run 0–59) returns a clear error instead of a confidently wrong description.

How to use this tool

1. Type a 5-part cron expression into the input field, click a preset chip, or use the field-by-field builder to construct one visually.
2. Click Explain to get a plain-English description, the Hangfire/Quartz.NET format comparison, and the next 5 run times.
3. Copy the final expression for use in your scheduler.

Hangfire vs Quartz.NET: why the formats differ

Hangfire uses the standard 5-field Unix cron format this tool already builds — minute hour day-of-month month day-of-week — passed directly to RecurringJob.AddOrUpdate(..., Cron.Custom("0 9 * * 1-5")) or one of Hangfire's Cron.* helper methods. Quartz.NET uses a 6-field format that adds a seconds field at the front — seconds minute hour day-of-month month day-of-week [year] — with an optional 7th year field. Two consequences of that extra precision: every Quartz expression this tool generates starts with a literal 0 seconds field (since the source 5-field expression has no seconds concept to preserve), and Quartz.NET enforces a rule Hangfire doesn't have — exactly one of day-of-month or day-of-week must be the wildcard ?, never both a specific value at once. This tool sets whichever field wasn't explicitly restricted to ? automatically. It also re-bases day-of-week numbering: standard cron uses 0–7 for Sunday–Saturday (both 0 and 7 mean Sunday), while Quartz.NET uses 1–7 for Sunday–Saturday — so a Hangfire 1-5 (Mon–Fri) becomes Quartz's 2-6.

Next run times — how they're computed, and the timezone caveat

The next 5 run times are computed by walking forward minute-by-minute from the current time (capped at 5 years out) and checking each candidate against all five fields — the same logic a real scheduler uses, just written for a preview rather than actually running jobs. As the section above explains, cron has no built-in timezone: this preview shows each run time in UTC and in this server's local timezone, not your browser's timezone, since a server-rendered page has no reliable way to read that without an extra round trip. If your scheduler runs in a specific timezone (Hangfire and Quartz.NET both support configuring one explicitly), convert accordingly.

Timezone considerations

The standard cron format has no timezone field — cron daemons run in the system timezone of the server. Cloud schedulers like AWS EventBridge and GitHub Actions workflows default to UTC. If your job needs to run at a specific local time, convert from your local timezone to UTC before writing the expression. For example, 9 AM IST (UTC+5:30) is 0 3:30 * * * in UTC, but since cron does not support half-hour offsets, adjust accordingly or use a platform that supports timezone-aware scheduling like Google Cloud Scheduler.