Skip to content

free_tool

Cron Expression Explainer

Five fields and a lot of asterisks. Paste a cron expression and get it back in plain English, plus the next five times it will actually fire, so you can be sure "0 0 1 * *" means what you think before it ships. It runs in your browser.

0 minute9 hour* day (month)* month1-5 day (week)

In plain English

At 09:00, on Monday, Tuesday, Wednesday, Thursday, and Friday.

Next 5 runs

Calculating…

Computed in UTC, the default for most schedulers and CI. Your local equivalents are shown alongside.

Cron is fine until a job overruns, double-fires, or silently dies and nobody notices for a week. I set up scheduled work that's idempotent, observable and alertable.

Make your jobs reliable: book a call

Standard 5-field cron, with ranges (1-5), lists (1,3,5), steps (*/15), names (MON, JAN) and macros (@daily). Day-of-month and day-of-week follow the usual rule: when both are set, a run matches if either does.

read_before_you_ship

The schedule you meant, not the one you typed

Cron's syntax is terse enough that a job firing every minute instead of once a day is a single misplaced asterisk away. Seeing the next few real run times is the fastest way to catch that before it's a 2am pager or a bill for a million executions.

The classic trap is day-of-month combined with day-of-week. Most people read it as "and"; cron reads it as "or" when both are set, so 0 0 13 * 5 runs every Friday and the 13th, not only on Friday the 13th. The run list makes that obvious at a glance.

faq

Questions & answers

What does the Cron Expression Explainer give me?
It parses a standard five-field cron expression and returns a plain-English description plus the next five run times. It supports ranges, lists, steps, month and day names, and macros like @daily and @hourly.
What timezone are the next run times in?
It computes the schedule in UTC and shows each run in both UTC and your local browser time, so you can read off the exact moments without doing the timezone math yourself.
Why does an expression with both day-of-month and day-of-week run more often than I expected?
When both fields are restricted, cron uses OR logic, so a schedule fires on either match, not only when both line up. Check the next five runs to confirm the schedule before you ship it.
Is the expression I paste sent anywhere?
No. Parsing and the next-run calculation happen entirely in your browser with no network call, so nothing you type is transmitted.
Why does it say there are no upcoming runs?
The expression is valid but no matching time exists in the look-ahead window, which happens with impossible dates like the 31st of February. Adjust the day or month so a real date can match.

Scheduled jobs you can't fully trust?

Overlapping runs, silent failures, jobs that fire twice or not at all. I'll make your scheduled work idempotent, observable and alertable. Book a call, or leave your email.

Book a call

No spam. You'll get a reply from me.

Prefer proof first? See how this plays out in real case studies →