← Blog  ·  October 2026

Cron Expression Tester: Parse and Validate Any Cron Schedule Online

Tags: cron  ·  DevOps  ·  Tools

Cron expressions are powerful and concise — but they're also easy to get wrong and surprisingly hard to read at a glance. Our free cron expression tester tells you exactly what any cron schedule means in plain English, and shows you the next several run times so you can verify the schedule before deploying it.

→ Test a cron expression now (free tool)

Paste any standard 5-field cron expression and get an instant human-readable interpretation: "Every Monday at 3:00 AM." No guessing, no counting fields.

Why cron expressions are hard to read

A cron expression looks deceptively simple. Five space-separated fields, each controlling a unit of time. But the combination of special characters — asterisks, slashes, commas, hyphens, and sometimes question marks — makes even experienced developers pause when reading an expression they didn't write themselves.

Is that "every Monday at 3:00 AM" or "the 1st of every month at 3:00 AM"? (It's Monday — field 5 is day-of-week, not day-of-month.) Now try this one:

*/15 9-17 * * 1-5

Every 15 minutes, between 9am and 5pm, Monday through Friday. Reasonable to figure out — but not instantly obvious. The moment you add ranges, step values, and multiple comma-separated values, the cognitive overhead compounds fast.

A cron expression tester removes that overhead entirely. Paste it in, read the English, confirm the next 5 run times, done.

The five cron fields explained

A standard cron expression has exactly five fields, separated by spaces:

The field order is always the same: minute, hour, day-of-month, month, day-of-week. A useful mnemonic: M H D M D — minute, hour, day, month, day-of-week.

Special characters

• * — every value in this field ("every minute", "every hour", etc.)
• */n — every nth value (e.g. */5 in the minute field = every 5 minutes)
• a-b — a range from a to b inclusive (e.g. 9-17 in the hour field = 9am through 5pm)
• a,b,c — a list of specific values (e.g. 1,15 in day-of-month = 1st and 15th)

Common cron expression patterns

Here are the most frequently used patterns and what they mean:

Unsure whether your expression matches what you intended? Paste it into the cron expression tester — it shows the next 10 scheduled run times, so you can immediately verify the pattern is correct.

Cron syntax varies by platform

Standard 5-field cron expressions work in Linux crontab, most Unix systems, and most job schedulers. But some platforms have their own variations — and knowing the difference can save you a frustrating debugging session.

GitHub Actions

GitHub Actions uses the same 5-field format with a UTC timezone. Note: GitHub documentation warns that scheduled workflows may run up to 15 minutes late during periods of high load. */5 in the minute field is the minimum interval GitHub allows.

on:
  schedule:
    - cron: '0 3 * * 1'  # Monday at 3:00 AM UTC

AWS EventBridge (CloudWatch Events)

AWS uses a 6-field cron format with an additional year field at the end, and uses ? as a wildcard for either day-of-month or day-of-week (not both can be specified). Their expressions look like:

cron(0 3 ? * MON *)   # Monday at 3:00 AM UTC, every year

AWS also supports named days (MON, TUE, etc.) and months (JAN, FEB, etc.) in addition to numeric values.

Kubernetes CronJob

Kubernetes uses standard 5-field cron syntax. The schedule field follows Unix cron conventions exactly. Timezones can be specified with a timeZone field in the spec (since Kubernetes 1.25).

Heroku Scheduler

Heroku Scheduler uses a simplified interface — every 10 minutes, every hour, or daily at a specific UTC time. It does not support arbitrary cron expressions.

How to validate a cron expression before deploying

The best practice before deploying any cron job is to validate the expression in three ways:

1. Parse the expression to plain English — confirm it means what you think it means
2. Check the next N run times — look at 5–10 upcoming runs to verify the pattern matches your intent, especially for complex expressions
3. Consider timezone — cron runs in the server's system timezone unless specified otherwise. A "3:00 AM" job on a server in UTC fires at 8:00 PM Pacific or 11:00 PM Eastern. Always confirm what timezone your scheduler uses.

Our cron expression parser handles all three: it gives you the plain-English translation, the next 10 run times, and lets you select a timezone for the preview. Paste in your expression, verify the output, then deploy with confidence.

After validation: monitoring your cron jobs

Validating the expression before deploy is step one. But once a cron job is running, a whole different class of problems can emerge: the job starts but fails partway through, auto-renewal processes stop running, or a scheduler itself goes down. Syntax validation doesn't catch runtime failures.

The standard pattern for detecting missed cron runs is a dead man's switch: your job pings a monitoring service on successful completion, and the service alerts you if the ping doesn't arrive within the expected window. One curl command at the end of your job is all it takes.

← All articles  ·  CronWatch  ·  Cron parser tool