More games at WuGames.ioSponsoredDiscover free browser games — play instantly, no download, no sign-up.Play

Cron Expression Parser

Free Cron Expression Parser: explain Unix, Linux & Quartz cron in plain English, preview next run times by timezone, and decode @daily, @reboot macros.

Next-run times are shown in this timezone
Common Examples

Cron Expression Parser - Parse and Explain Cron Schedules

A powerful online Cron Expression Parser that helps you understand, validate, and explain cron schedule expressions. Supports both Unix/Linux (5 fields) and Quartz (6-7 fields) formats with detailed field breakdown and next run time preview. Perfect for understanding existing cron jobs and validating cron syntax.

What is a cron expression and how do I read one?

A cron expression is a 5 or 6-field string that defines when a recurring job should run. The standard Unix cron has 5 fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-6, Sunday is 0 or 7). Many newer schedulers (Quartz, Spring, Jenkins, AWS EventBridge) add a 6th seconds field at the front and a 7th year field at the end. The string "0 9 * * 1-5" means "at 09:00 on Monday through Friday." The character * means "every value," / means "step" (*/15 = every 15), - means range (1-5), and , means list (1,3,5). The Vixie cron man page is the canonical reference for the original 5-field format, RFC 4954 covers some scheduling semantics, and Quartz docs cover the extended dialect.

How do I find the next run time of a cron expression?

Paste the expression into the parser and read the "Next Run Times" card — it lists the next 5-10 fire times and a live countdown to the very next one. Crucially, pick the right timezone from the dropdown first: this tool computes the matched wall-clock times in the timezone you select (UTC, Asia/Tokyo, etc.), not just reformats a single instant, so the previewed runs are correct even when your browser is in a different zone. To verify a schedule before deploying, change the timezone to whatever your server/cluster uses and confirm the next runs land where you expect. Macros like @daily expand to 0 0 * * * and preview normally; @reboot has no clock time (it fires once at daemon start) so it shows a startup note instead of a list.

What's the difference between */5 and 0/5 in the minute field?

Both mean "every 5 minutes starting from 0," but they reach there by different syntactic paths. */5 means "step 5 over the entire range," producing 0, 5, 10, 15, ..., 55. 0/5 is the Quartz/Spring extended syntax meaning "start at 0, step by 5," identical in result. However, 3/5 explicitly means "start at 3 then step 5": 3, 8, 13, 18, ..., 58. The standard Vixie cron does not support N/M syntax (only */M); if you write 3/5 in a vanilla Linux crontab, it will silently fail or be misinterpreted. Always check whether your target runtime uses Vixie cron, croniter (Python), node-cron, Quartz, or Spring — they differ in this exact corner. AWS EventBridge in particular uses a Quartz-like 6-field format and quirky day-of-week semantics.

Why are day-of-month and day-of-week both interpreted as OR, not AND?

This is the single most surprising cron rule. "0 0 13 * 5" does NOT mean "the 13th of the month AND only on Friday" — it means "the 13th of any month, OR any Friday." When both day-of-month and day-of-week are restricted (neither is *), classic Vixie cron and most descendants treat them as a union, not an intersection. The original BSD cron used intersection, but Vixie cron deliberately switched to union in 1992 to match user expectations for things like "weekdays plus the 1st" ("0 9 1 * 1-5" = 9 AM on weekdays OR on the 1st of any month). To get the actual intersection (true Friday the 13th alerts), you typically need a guard inside the job itself, or use Quartz's special ? in one of the day fields to disambiguate. The Quartz spec requires that exactly one of day-of-month/day-of-week be ? to make this unambiguous.

What do @reboot, @daily, @weekly, @yearly, and @hourly mean?

These nicknames are shortcuts defined by Vixie cron for common schedules. @yearly (alias @annually) = 0 0 1 1 * (midnight on January 1). @monthly = 0 0 1 * * (midnight on the 1st). @weekly = 0 0 * * 0 (midnight on Sunday). @daily (alias @midnight) = 0 0 * * * (midnight every day). @hourly = 0 * * * * (top of every hour). @reboot is special: it runs once when the cron daemon starts, typically at system boot — useful for service startup tasks but unreliable in containerized environments where the cron daemon may restart for other reasons. systemd timers and Kubernetes CronJobs do not support @reboot semantically. Some flavors also support @minutely (every minute) but it's non-standard.

Cron Expression Parser — Free Cron Expression Parser: explain Unix, Linux & Quartz cron in plain English, preview next run times by timezone, and
Cron Expression Parser

How do I run a job every 5 minutes between 9 AM and 5 PM on weekdays?

The expression is "*/5 9-17 * * 1-5" meaning every 5 minutes (minute 0, 5, 10, ..., 55) of hours 9 through 17, any day of month, any month, Monday through Friday. Two subtleties: this fires at 17:00, 17:05, ..., 17:55 too — not 17:00 only. To stop at 17:00 sharp, use "*/5 9-16 * * 1-5" + "0 17 * * 1-5". Also, day-of-week 1-5 is Monday-Friday in Linux cron, but in Quartz and AWS EventBridge, Sunday is 1 and Saturday is 7, so Monday-Friday is 2-6 — a frequent off-by-one bug. Always test in your target scheduler. Online cron parsers like the one on this page show the next 5-10 run times so you can sanity-check the expression visually.

What is the difference between cron, systemd timers, and Kubernetes CronJobs?

All three schedule recurring jobs but with different guarantees. Classic Unix cron is simple, ubiquitous, but has no logging, no dependency tracking, no retries, and silently emails errors to root. systemd timers are the modern Linux replacement: they integrate with the journal (structured logs), support OnBootSec / OnCalendar (richer than cron syntax), handle missed runs (Persistent=true catches up if the system was off), and have unit dependencies. Kubernetes CronJobs use a Quartz-like 5-field cron expression but add concurrencyPolicy (Allow/Forbid/Replace), startingDeadlineSeconds, and successful/failed history limits. Cloud schedulers (AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps) add retries, dead-letter queues, and observability. For anything beyond a hobby server, prefer systemd timers or a cloud scheduler over raw cron.

What's the difference between L, W, and # in Quartz cron expressions?

These are Quartz extensions not found in standard Vixie cron. L means "last": L in day-of-month = the last day of the month (handles 28/29/30/31 automatically), 5L in day-of-week = the last Friday of the month. W means "weekday nearest": 15W = the weekday closest to the 15th (if the 15th is Saturday, it triggers Friday the 14th; if Sunday, Monday the 16th). LW combined = the last weekday of the month — useful for payroll. # specifies the Nth occurrence: 2#3 in day-of-week = the third Tuesday of the month (since Quartz uses 1=Sun, 2=Mon, ..., 7=Sat). These extensions handle real-world business rules ("second Monday of every month", "last business day for invoices") that pure 5-field cron cannot express. AWS EventBridge supports L and # but not W.

How do timezones affect cron schedules?

Classic Vixie cron runs in the system's local timezone (TZ env var), which causes painful bugs around daylight saving time transitions. In a timezone with spring-forward, jobs scheduled at 02:30 simply don't run on that day. With fall-back, jobs at 01:30 run twice. systemd timers default to UTC unless OnCalendar specifies a TZ. Quartz and Kubernetes CronJobs both support an explicit timezone field (spec.timeZone in CronJob 1.27+) so the same expression behaves identically across regions. AWS EventBridge interprets cron in UTC always; rate(...) expressions are timezone-independent. Best practice: write all cron expressions in UTC and convert for display. If you must use local time, avoid the daylight saving edge hours (02:00-03:00 in most regions); schedule jobs at 04:00 or later instead.

Key Features

  • Parse and explain cron expressions in plain English
  • Support for Unix/Linux (5 fields) and Quartz (6-7 fields) formats
  • Automatic format detection
  • Field-by-field breakdown with detailed explanations
  • Real-time validation with error messages
  • Calculate and preview next 5-10 run times in any timezone
  • Cron nickname macros: @daily, @hourly, @weekly, @monthly, @yearly, @reboot
  • Common expression examples for testing
  • Understands special characters: * , - / ? L (W and # rejected as unsupported)
  • Month and day name support (JAN-DEC, SUN-SAT)
  • Copy expression to clipboard
  • 100% client-side - no data sent to server
  • Works offline after initial load
  • Mobile-friendly responsive design
  • Dark mode support