Cron expression generator

A cron expression is a compact, five-field pattern used to schedule recurring jobs on Unix-like systems, in CI/CD pipelines such as GitHub Actions and GitLab CI, in cloud schedulers like AWS EventBridge and Google Cloud Scheduler, and inside application frameworks such as Node.js (node-cron), Django, Laravel, and Spring. Each of the five fields represents a unit of time — minute, hour, day of month, month, and day of week — and together they describe exactly when a task should run. Because the syntax is terse, it is very easy to get subtly wrong: a single stray character can turn a daily job into one that fires every minute. That is exactly why a dedicated cron explainer that reads the expression back in plain English, and shows you the literal next few run times, is the fastest way to confirm a schedule does what you actually intended before it ships to production.

This page gives you both halves of that workflow in a single tool: an explainer for existing expressions and a builder for creating new ones from simple presets, so you never have to hand-write the syntax from memory.

The tool above gives you two complementary modes, switchable with the toggle at the top:

• Explain a cron: paste any standard 5-field cron expression into the input box and it is parsed instantly, with no server round-trip and nothing leaving your browser. You will see a plain-English summary, a field-by-field breakdown of exactly what each of the five positions means, and the next five times the job will actually run in your local timezone.
• Build a cron: pick a schedule type — every minute, every N minutes, hourly, daily, weekly on a chosen weekday, or monthly on a chosen date — fill in the time, and the correct cron expression is generated and validated for you automatically. Click Copy to grab it for your crontab, CI config, or scheduler, with a brief confirmation once it is on your clipboard.

Everything runs client-side in JavaScript, so the tool works offline once the page has loaded and never sends your schedule to a server, which makes it safe to use even with internal or sensitive job names.

A standard cron expression always has exactly five space-separated fields, in this fixed order:

Note on the day-of-week field: some cron implementations accept named months (JAN-DEC) and named weekdays (SUN-SAT) as a convenience. The parser behind this tool only accepts numeric values in every field, and treats both 0 and 7 as Sunday, folding 7 down to 0 internally — so 0 9 * * 0 and 0 9 * * 7 both mean “every Sunday at 9am.” If you paste a month or weekday name into the fields above, it will be flagged as invalid rather than silently accepted.

Each field also supports a small set of syntax patterns, all of which this generator supports:

• * — a wildcard meaning “every” value for that field.
• */n — a step value, meaning every n units. For example */5 in the minute field means every 5 minutes.
• a-b — an inclusive range. For example 1-5 in the day-of-week field means Monday through Friday.
• a-b/n — a stepped range. For example 0-30/10 in the minute field means minute 0, 10, 20, and 30 only.
• a,b,c — a comma-separated list of specific values. For example 1,15 in the day-of-month field means the 1st and the 15th only.
• A single plain number — an exact value for that field, with no repetition.

Here are the schedules people look up most often, along with the plain-English meaning the explainer above would give you for each one:

Paste any of these into the explainer above to see the field-by-field breakdown and the exact next five run times computed from your current local clock.

*/5 * * * * is one of the most common cron expressions in the wild, and it means every 5 minutes. Reading it field by field: the minute field is */5, a step value that runs the job whenever the minute is divisible by 5 — that is minute 0, 5, 10, 15, 20, and so on up to 55. The remaining four fields are all *, the wildcard meaning “every,” so the job fires every hour, every day of the month, every month, and every day of the week. Put together, this expression triggers 12 times per hour, 288 times per day, forever. Paste it into the explainer above to confirm the next five run times for yourself, or change the 5 to any other number of minutes you need.

Some cron implementations — notably Vixie cron and systems that wrap it, like many Linux distributions — support shorthand “nickname” strings in place of the five numeric fields:

Important: the table above is reference information only. The explainer and builder on this page work exclusively with the standard 5-field numeric syntax and do not parse or generate @daily, @hourly, @weekly, @monthly, @yearly/@annually, or @reboot. If you paste one of these strings into the explainer, it will be reported as an invalid expression because it does not split into five fields. If your target system supports these nicknames and you want to use one directly, you can — just know that this tool will always output (and only understands) the fully spelled-out five-field form, which is also the more portable option across schedulers that do not support the shorthand at all.

One of the most common sources of “why did my job run at the wrong time” confusion is timezone handling. A cron daemon has no concept of the visitor's browser timezone — it simply reads the system clock of the machine (or container) it is running on, which is normally set to either UTC or the server's configured local timezone. If you write 0 9 * * * intending “9am for me,” but the server that actually runs the job is set to UTC and you are five hours behind it, the job will fire at what feels like 4am your time.

The Next 5 runs panel in the explainer above shows times in your browser's local timezone, purely so you can sanity-check the pattern of the schedule (every day, every 5 minutes, and so on). It cannot know what timezone the server that will actually execute your crontab, CI job, or cloud scheduler entry is configured with. Before deploying a time-sensitive schedule, always check the timezone setting of the system that will run it — many cloud schedulers (like AWS EventBridge and Google Cloud Scheduler) let you set an explicit timezone per schedule, which is the safest way to avoid daylight saving time surprises twice a year.

Cron expressions power a huge share of the automation running behind the scenes of most software:

• Database and file backups — a nightly 0 2 * * * job that dumps a database or backs up a directory while traffic is low.
• Cache clearing and warming — periodically flushing a stale cache or pre-warming it ahead of expected traffic, often on an hourly or every-15-minutes schedule.
• Scheduled report emails — sending a daily or weekly summary to stakeholders, for example every weekday morning with 0 8 * * 1-5.
• Health checks and monitoring pings — hitting an endpoint every few minutes with */5 * * * * to confirm a service is still responding before a customer notices it is not.
• Log rotation and cleanup — archiving or deleting old log files on a nightly or weekly cadence to keep disks from filling up.
• Billing and subscription renewals — running charge or renewal logic once a day or once a month on a fixed date, such as 0 0 1 * * for the first of the month.
• Data syncs and ETL pipelines — pulling data from an external API or warehouse on a recurring interval to keep downstream systems up to date.
• CI/CD nightly builds — triggering a full test suite or nightly build outside business hours so it does not compete with active development for CI runners.

• Cron runs in the server's configured timezone, not necessarily yours — always check it before relying on an exact time (see the timezone section above).
• Combining a specific day-of-month and a specific day-of-week (both non-wildcard) usually means “OR” on most cron implementations, which surprises people — prefer leaving one of the two as * unless you deliberately want the OR behavior.
• Avoid scheduling exactly on day 29, 30, or 31 for a monthly job unless you have accounted for shorter months — February, for instance, will simply never trigger a day-31 job.
• Always run a new expression through a cron explainer before deploying it — a single misplaced field can silently turn a daily job into one that runs every minute, which can overload a downstream system fast.
• For very frequent jobs (every minute or every few minutes), make sure the job reliably finishes faster than the interval, or add locking, so overlapping runs cannot stack up on a slow day.
• Prefer the fully spelled-out five-field form over shorthand nicknames like @daily when portability across different tools and schedulers matters, since not every system supports the shorthand.