acento.io
Developer tool

Cron Expression Parser

Paste a cron expression and see exactly what it means — plus the next 10 scheduled run times in UTC and your local timezone. 100% client-side, nothing leaves your browser.

By Carlos Suárez , Systems engineer
Last updated:

What this cron expression parser does

Cron has been scheduling Unix jobs since the 1970s — its syntax is terse by design, and even experienced engineers misread a field now and then. This English-language cron expression evaluator translates any standard 5-field expression (minute hour day-of-month month day-of-week) into plain language and lists the next 10 upcoming executions side by side in UTC and your browser's local time. It supports wildcards, ranges like 1-5, comma-separated lists like 1,3,5, step values like */15, and the common aliases @daily and @hourly. Because computing runs on UTC internally — the Unix epoch starts at 1970-01-01 00:00:00 UTC — seeing both columns at once helps you reason about a job's real wall-clock impact. 100% client-side — your data never leaves your browser. No uploads, no tracking, no server logs.

Features

  • Plain-language translation. Every parsed expression is rendered in a human-readable sentence so you can confirm the intended schedule at a glance without mentally mapping field positions.
  • Next 10 execution times. Preview the upcoming 10 run times in both UTC and your detected local timezone — useful when a job's server clock differs from your team's location.
  • Full syntax support. Handles all standard 5-field cron syntax: *, ranges (1-5), lists (1,3,5), steps (*/15), and shorthand aliases like @hourly, @daily, @weekly, and @monthly.
  • Implementation difference warnings. The tool flags known gotchas: POSIX cron treats day-of-month and day-of-week with OR logic, while Quartz Scheduler and Spring use AND. Sunday is field value 0 or 7 in classic cron but 1 in Quartz. Knowing which scheduler you're targeting matters.
  • DST and timezone awareness. Cron itself has no timezone concept — it follows the system clock. The tool notes that DST transitions can cause jobs to skip or run twice, and recommends UTC-based scheduling for predictability.
  • No install, no account. Works entirely in your browser. There is no server-side evaluation, no rate limit, and no signup. Pair it with our [Unix timestamp converter](/en/timestamp-converter/) when you need to verify exact epoch values for a scheduled event.

How to use the cron expression parser

Type or paste a cron expression into the input field and results update instantly.

  1. Enter a 5-field expression. Type your expression in the input — for example, 0 9 * * 1-5 means every weekday at 09:00. The placeholder shows this format by default.
  2. Read the plain-language summary. The "In plain language" panel rewrites the schedule in a full English sentence — no field counting required.
  3. Check the next 10 runs. The execution table shows the next 10 trigger times in both UTC and your local time. If you're in Seattle or Boston coordinating a job on a Sydney-based server, this dual view prevents off-by-one-day surprises.
  4. Try shorthand aliases. Enter @daily or @hourly to see how they expand. Aliases are a clean alternative to 0 0 * * * and 0 * * * * and are supported by most POSIX-compatible schedulers.
  5. Note implementation warnings. If your expression combines day-of-month and day-of-week fields, the tool will remind you whether your target scheduler (crontab, Quartz, AWS EventBridge) treats them as OR or AND — a frequent source of unexpected behavior.

Common use cases

  • Validating a schedule before deploy. Paste the expression from your crontab or CI config before you push. Catching */5 * * * * when you meant 0 */5 * * * in staging is much cheaper than in production.
  • Explaining a schedule to non-engineers. The plain-language output lets you copy a one-liner into a ticket or Slack message so product managers and stakeholders understand when a batch job will run without reading cron docs.
  • Estimating next run for long-running jobs. Monthly or quarterly jobs are easy to miscalculate. Seeing the next 10 occurrences in a table makes it obvious whether 0 2 1 * * fires on the first of the month or the first weekday.
  • Teaching cron syntax. The instant feedback loop makes this a solid teaching tool. New engineers can experiment with ranges and steps and immediately see the effect — far faster than deploying a test job. You can also use the [date calculator](/en/date-calculator/) to cross-check relative date offsets.
  • Auditing legacy crontabs. When inheriting a server with a dense crontab, running each line through the online cron parser gives you a readable inventory of what runs when — useful before any infrastructure migration.

Frequently asked questions

Does this tool send my cron expression to a server?

No. All parsing happens inside your browser using JavaScript. Nothing is transmitted, logged, or stored. You can use it on an air-gapped machine if needed.

Why does my expression behave differently in Quartz vs. standard crontab?

Standard POSIX cron uses 5 fields and treats day-of-month and day-of-week with OR logic — the job runs if either condition matches. Quartz Scheduler and Spring use a 6-7 field format that adds seconds (and optionally year) and applies AND logic between day fields. This tool parses standard 5-field syntax. If you're targeting Quartz or AWS EventBridge, double-check the field count and logic in their docs before relying on any online cron parser.

What does `*/15` mean in the minute field?

The step operator / divides the field range into intervals. */15 in the minute field means every 15 minutes: at :00, :15, :30, and :45 of every hour. You can combine it with a range: 0-30/10 fires at :00, :10, :20, and :30.

Will my job skip or run twice during a daylight saving time change?

It depends on your scheduler. Classic cron has no timezone awareness — it follows the system clock, so when clocks fall back an hour, any job scheduled in that hour can fire twice. When clocks spring forward, that hour is skipped entirely. Modern schedulers like systemd timers let you specify a timezone explicitly and handle DST correctly. Scheduling in UTC avoids the problem entirely, which is why most cloud schedulers (AWS EventBridge, GCP Cloud Scheduler) operate in UTC internally.

Is Sunday field value 0 or 7?

Both are accepted by most POSIX-compatible crontab implementations — 0 and 7 are treated as Sunday. However, Quartz Scheduler uses a 1-based numbering where Sunday is 1 and Saturday is 7, which is completely different. Always verify against your specific scheduler's documentation to avoid a day-of-week off-by-one error.

Can I use this as a cron job expression evaluator for AWS EventBridge or GitHub Actions?

For GitHub Actions, the workflow schedule trigger uses standard 5-field UTC cron syntax, so this tool maps directly. AWS EventBridge uses a 6-field cron with a required year field and its own day-of-month/day-of-week semantics — you'll get a useful approximation here, but confirm field meanings in the EventBridge docs. For time-math that complements your scheduling work, the [time calculator](/en/time-calculator/) can help you add or subtract durations.