Cron expression explainer — plain English, field breakdown, next run times

Use this free cron expression explainer online to decode five-field Unix cron strings: see each of minute, hour, day-of-month, month, and day-of-week in a table, read a human-readable schedule summary, and preview upcoming execution times in your local timezone. When both DOM and DOW are specific, the tool warns about the classic Vixie-style OR rule so you do not misread inherited crontab lines. Parsing stays in your browser—paste from Linux cron, Kubernetes CronJob, serverless schedules, or CI without uploading secrets. Pair decoding with our JSON formatter for pipeline configs and the regex tester when schedules embed pattern-heavy names.

Order: minute · hour · day-of-month · month · day-of-week. One space between fields.

Valid 5-field cron

FieldValue
Minute (0–59)0
Hour (0–23)9
Day of month (1–31)*
Month (1–12 or JAN–DEC)*
Day of week (0–7, SUN–SAT; 0/7 = Sunday)1-5

Plain-language summary

  • Runs when the clock shows minute 0 and hour 9 (24-hour clock) (when the date rules below match).
  • Calendar filter: Monday, Tuesday, Wednesday, Thursday, Friday.
  • Month filter: January through December (all months).

Next run times (local)

  1. Apr 6, 2026, 9:00 AM
  2. Apr 7, 2026, 9:00 AM
  3. Apr 8, 2026, 9:00 AM
  4. Apr 9, 2026, 9:00 AM
  5. Apr 10, 2026, 9:00 AM
  6. Apr 13, 2026, 9:00 AM
  7. Apr 14, 2026, 9:00 AM
  8. Apr 15, 2026, 9:00 AM
  9. Apr 16, 2026, 9:00 AM
  10. Apr 17, 2026, 9:00 AM
  11. Apr 20, 2026, 9:00 AM
  12. Apr 21, 2026, 9:00 AM

Calculated from when you loaded or changed this page; refresh to re-anchor “now.” Uses your device timezone.

Why use a cron schedule explainer?

Operations and platform engineers constantly ask what does this cron expression mean when onboarding to a legacy server, reviewing Terraform or Helm, or auditing GitHub Actions and cloud function triggers. A dedicated cron translator turns opaque stars, slashes, and comma lists into sentences you can share with security, support, and product teams. Unlike a wall of documentation, you paste the exact string and immediately see whether a job is daily, weekly, or something stranger, plus a short list of next cron run times to sanity-check intent before you change production.

If you also validate deployment artifacts, keep YAML and JSON consistent across environments, and use our SQL formatter when cron jobs touch reporting queries.

How the five cron fields work (quick guide)

Standard Unix crontab format uses five columns, left to right: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or JAN–DEC), and day of week (0–7 or SUN–SAT, where 0 and 7 often both mean Sunday). An asterisk * means "every" for that column. Ranges like 1-5, steps like */15, and lists like 1,15 combine the usual way. This page does not cover Quartz-only tokens such as ?, L, or six-field second-level schedules.

The day-of-month vs day-of-week OR rule

The most common misunderstanding in cron expression meaning threads is how two specific calendar columns interact. On typical Vixie-style cron, when both day-of-month and day-of-week are restricted (neither is *), the job runs if either matches—not only when both match. That is why 30 4 1,15 * 5 fires at 4:30 AM on the 1st and 15th and every Friday. Our explainer surfaces that warning whenever it applies so your schedule audit catches surprises before a deploy.

How to use this cron explainer (step by step)

  1. Paste a single line with five fields—often copied from crontab -e, a dashboard, or infrastructure-as-code. Click Load sample (0 9 * * 1-5) for 09:00 on weekdays.
  2. Read the field table to confirm each column lines up with what your platform expects (some UIs hide seconds or use UTC labels).
  3. Review the plain-language bullets and any amber Heads-up callouts—especially for combined DOM and DOW constraints.
  4. Compare next run times against your expectations. Remember they use your browser's local timezone; production hosts may differ—align with TZ or orchestrator settings before you rely on them for alerts.
  5. When you need to inspect URLs your batch jobs call, use the HTTP header checker or redirect chain checker on the same site to verify endpoints your cron hits.

Keywords teams search for (and how this page maps to them)

People look for a crontab explainer, cron schedule reader, human readable cron, or decode cron online when docs are scattered across Linux man pages, cloud vendor consoles, and SaaS job runners. This utility targets those intents with an interactive field table, narrative summary, and projected runs without sign-up. For structured data work adjacent to batch jobs, the CSV to JSON and JSON to CSV converters help normalize exports your cron produces or consumes.

Timezones, DST, and production checklists

A cron expression checker in the browser explains intent, but runtime still depends on where the scheduler runs. Containers may default to UTC while your laptop shows local time; daylight saving shifts can move wall-clock hours even when UTC offsets look stable. Treat this page as a design-time explainer, then confirm with your platform's execution logs or a staging trigger. For external reachability checks tied to maintenance windows, our HTTP response code checker complements that workflow.

Limitations vs full orchestrators

Kubernetes, AWS EventBridge, and managed cron products sometimes extend or subset classic syntax. This tool implements the widespread five-field rules plus month and weekday names—enough for many Linux cron expression examples. It does not evaluate @yearly, @monthly, @weekly shorthands or per-user timezone files. When vendors disagree, trust their docs and use this explainer as a first pass only.

Related developer tools

Explore the full code and developer tools catalog. Highlights:

  • JSON Formatter & ValidatorFormat, validate, minify, and explore JSON in a collapsible tree—fix payloads before they hit production.
  • JSON to CSV ConverterTurn JSON arrays into downloadable CSV with automatic column detection for spreadsheets and BI tools.
  • JSON to YAML ConverterConvert JSON to readable YAML for configs and Kubernetes—copy or download the result.
  • CSV to JSON ConverterPaste or upload CSV and get structured JSON with header-aware typing for APIs and apps.
  • YAML to JSON ConverterParse YAML to valid JSON with clear errors—ideal for CI configs and cloud templates.
  • XML Formatter & ValidatorBeautify and validate XML with structure insight and actionable parse errors.
  • Regex Tester & DebuggerTest patterns live with highlights, capture groups, and flags—debug regex without leaving the browser.
  • SQL FormatterPretty-print SQL with indentation and keyword casing for readable queries and code review.
  • HTML Formatter & MinifierBeautify or minify HTML and compare raw markup with a quick rendered preview.
  • CSS Formatter & MinifierFormat messy stylesheets or minify CSS for faster loads—keep design tokens consistent.
  • JavaScript Formatter & MinifierPretty-print or minify JavaScript for debugging locally and shipping smaller bundles.
  • HTML to Markdown ConverterConvert HTML snippets to Markdown for docs, CMS migrations, and README cleanup.
  • Markdown to HTML ConverterTurn Markdown into HTML with a live preview—handy for emails, blogs, and static pages.
  • Code Diff CheckerCompare two code blocks side by side with clear add/remove highlighting for reviews.

Frequently asked questions

What is a cron expression?
A cron expression is a compact schedule string used by Unix-style schedulers (cron, systemd timers, Kubernetes CronJob, cloud functions, and CI cron). The common five-field form is: minute, hour, day-of-month, month, and day-of-week, separated by spaces.
What does this cron explainer do?
Paste a five-field cron string to see a plain-English breakdown of each part, any important warnings (such as the day-of-month vs day-of-week OR rule), and the next several run times calculated in your browser using your local clock.
Is my cron expression sent to a server?
No. Parsing and next-run calculation run entirely in your browser with JavaScript. Nothing is uploaded unless you use another page that explicitly makes network requests.
Why do day-of-month and day-of-week both matter?
In Vixie-style cron, when both day-of-month and day-of-week are restricted (not *), the job runs if either field matches—not only when both match. For example, 30 4 1,15 * 5 runs at 4:30 AM on the 1st and 15th of each month and also every Friday. This tool surfaces that behavior so you are not surprised in production.
Does this support seconds, years, or Quartz extensions?
This page focuses on the standard five-field Unix cron. Six-field schedules with seconds, the question-mark (?) placeholder from Quartz, L/W/# modifiers, and @yearly-style aliases are not parsed here—use your platform’s documentation for those variants.
Can I use month or weekday names?
Yes. Month abbreviations JAN through DEC are accepted in the month field. Day-of-week accepts SUN through SAT (Sunday is 0 or 7 in many crons; this tool normalizes Sunday consistently for matching and explanations).
Which timezone are the “next runs” in?
Next run times use your browser’s local timezone, same as JavaScript Date. Cron on a server uses the server’s timezone unless configured otherwise—always confirm TZ in production.
How is this different from a cron builder or generator?
An explainer starts from an existing string (for example from crontab -l, GitHub Actions, or a Terraform schedule) and translates it. A generator or UI builder helps you compose a new expression from dropdowns. Use both when you inherit schedules or audit automation—see also our developer tools index for formatters and testers you can pair with pipeline YAML.