What is the difference between * and ? in a cron expression?

In classic five-field cron expressions, * is a wildcard that matches every value in a field (e.g., * in the hour field means every hour). The ? character is not used in standard cron expressions; it appears in some schedulers like Quartz to indicate "no specific value" for day-of-month or day-of-week when the other field is set. The Cron Parser tool only supports standard five-field expressions, so ? is not valid.

Can I use cron expressions to run a task every 30 seconds?

No, classic five-field cron expressions cannot run tasks more frequently than once per minute. The smallest unit is minutes, so */1 in the minute field runs every minute. To run a task every 30 seconds, you’d need a scheduler that supports seconds (like Quartz) or a different approach, such as a loop in a script.

How do I schedule a task to run on the last day of the month?

In standard cron expressions, you can use the highest valid day-of-month value (e.g., 31) and combine it with a month field that excludes months with fewer days (e.g., 2 for February). For example, 0 0 31 1,3,5,7,8,10,12 * runs at midnight on the last day of months with 31 days. Some schedulers like Quartz support the L character (e.g., 0 0 L * * ), but the Cron Parser tool does not.

Why does my cron expression run at unexpected times?

The most common reason is a time zone mismatch. Cron expressions are time-zone agnostic, but the scheduler that executes them uses a specific time zone. For example, if your server is in UTC and you schedule a task for 9:00 AM, it will run at 9:00 AM UTC, not 9:00 AM in your local time zone. Always check the scheduler’s time zone settings and use the Cron Parser tool to see run times in both local and UTC time zones.

Can I use names like MON or JAN in a cron expression?

Yes, most schedulers support abbreviated month and day-of-week names (e.g., JAN-DEC for months, SUN-SAT for days). For example, 0 9 * * MON is equivalent to 0 9 * * 1 . The Cron Parser tool normalizes expressions to use names for readability, but you can enter either format.

How do I test a cron expression before deploying it?

Use the Cron Parser tool to validate the expression, read the plain-English summary, and review the next five run times. This confirms the schedule matches your intent. For production environments, also test the expression in a staging environment with the same scheduler and time zone settings as your production server.

Parse a Cron Expression and See Next Run Times Instantly

A cron expression is a compact five-field string that tells schedulers like cron, Quartz, or Spring when to run a task. The fields, in order, are minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), and day-of-week (0-7, where both 0 and 7 mean Sunday). Each field accepts numbers, wildcards (*), comma-separated lists, inclusive ranges (e.g., 1-5), or steps (e.g., */15). For example, 0 9 * * 1 runs at 9:00 AM every Monday. Parsing a cron expression manually to check syntax or predict run times is error-prone, especially when wildcards or steps span multiple values. The Cron Parser tool solves this by validating the expression, summarizing each field in plain English, and calculating the next five matching times in both local and UTC time zones. This lets you confirm the schedule matches your intent before deploying it to production.

Cron expressions are widely used in automation, from simple backups to complex workflows. A misplaced wildcard or incorrect range can cause tasks to run at the wrong time, overload servers, or miss critical deadlines. For instance, 0 0 1 * * runs at midnight on the first day of every month, but 0 0 * * 1 runs at midnight every Monday. The difference is subtle but critical. The Cron Parser tool eliminates guesswork by showing exactly which days and times the expression selects. It also handles edge cases like month-end days (e.g., L in some schedulers) or non-standard steps (e.g., */3 for every third hour). Whether you’re scheduling a daily report, a weekly cleanup job, or a monthly database backup, parsing the expression first ensures the task runs when you expect it to.

How Cron Expressions Work

Cron expressions consist of five mandatory fields separated by spaces. Each field has a specific range and purpose:

Field	Range	Allowed Values	Example
Minute	0-59	Numbers, , ranges (e.g., 0-30), lists (e.g., 0,15,30,45), steps (e.g., /5)	`0`, ``, `0-30`, `/15`
Hour	0-23	Numbers, *, ranges, lists, steps	`9`, `0-11`, `*/2`
Day-of-month	1-31	Numbers, *, ranges, lists, steps, `L` (last day, in some schedulers)	`1`, `*`, `1-15`, `L`
Month	1-12	Numbers, *, ranges, lists, steps, or names (e.g., JAN-DEC)	`1`, `*`, `1-6`, `JAN,MAR,MAY`
Day-of-week	0-7 (0 and 7 = Sunday)	Numbers, *, ranges, lists, steps, or names (e.g., SUN-SAT)	`0`, `*`, `1-5`, `MON-FRI`

Wildcards (*) match every possible value in a field. For example, * * * * * runs every minute. Ranges (e.g., 1-5) include all values between the start and end, inclusive. Lists (e.g., 1,3,5) match any of the specified values. Steps (e.g., */15) match every nth value, starting from the first. Some schedulers, like Quartz, add extra fields for seconds or years, but the classic five-field format is the most common and is what the Cron Parser tool supports.

Parse a Cron Expression Step by Step

Open the Cron Parser tool in your browser. No installation or sign-up is required.
Enter your cron expression in the input field. Use exactly five fields in the order minute, hour, day-of-month, month, and day-of-week. For example: 0 9 * * 1.
Click "Parse" or press Enter. The tool will validate the expression and display:
- A normalized version of the expression (e.g., 0 9 * * MON).
- A plain-English summary of each field (e.g., "At minute 0, hour 9, every day of the month, every month, on Monday").
- The next five run times in your local time zone and UTC.
Review the summary and run times to confirm the schedule matches your intent. For example, if you entered 0 9 * * 1, the summary should say "on Monday," and the run times should all be Mondays at 9:00 AM.
If the expression is invalid, the tool will show an error message with the field that failed validation. Correct the syntax and try again.
Once validated, copy the normalized expression or run times to use in your scheduler configuration.

Common Cron Expression Examples

Here are practical examples of cron expressions and their meanings:

Expression	Meaning	Use Case
`0 * * * *`	Every hour at minute 0	Hourly log rotation
`0 0 * * *`	Every day at midnight	Daily database backup
`0 9 * * 1`	Every Monday at 9:00 AM	Weekly team meeting reminder
`0 0 1 * *`	On the first day of every month at midnight	Monthly billing report
`0 0 * * 0`	Every Sunday at midnight	Weekly cleanup job
`/15 * * *`	Every 15 minutes	Health check ping
`0 0 1 1 *`	At midnight on January 1	Annual archive task

These examples show how wildcards, steps, and specific values combine to create flexible schedules. The Cron Parser tool helps you verify these expressions by translating them into plain language and showing the next run times. For instance, */15 * * * * will show run times every 15 minutes, while 0 9 * * 1 will confirm the task runs only on Mondays.

Time Zones and Scheduler Compatibility

Cron expressions are time-zone agnostic, but the scheduler that executes them is not. The Cron Parser tool shows run times in both your local time zone and UTC, but your scheduler may use a different time zone. For example, if your server is in UTC+2 and you schedule a task for 0 9 * * *, the task will run at 9:00 AM UTC+2, not 9:00 AM in your local time zone. Always confirm the time zone settings of your scheduler to avoid mismatches. Common schedulers include:

Unix cron: Uses the system’s local time zone. Run date in the terminal to check.
Quartz (Java): Defaults to the JVM’s time zone but can be configured per trigger. See the Quartz documentation for details.
Spring Boot: Uses the server’s time zone. Configure it with spring.task.scheduling.time-zone in application.properties.
AWS CloudWatch Events: Uses UTC by default. You can override this in the rule settings.

The Cron Parser tool also helps you test expressions for edge cases, like daylight saving time transitions. For example, if you schedule a task for 0 2 * * * in a time zone that observes DST, the task may run twice or not at all when the clock changes. The tool’s run times will reflect this, allowing you to adjust the schedule if needed.

Troubleshooting Invalid Expressions

If the Cron Parser tool rejects your expression, check for these common mistakes:

Wrong number of fields: Classic cron expressions must have exactly five fields. Quartz expressions, which include seconds or years, are not supported.
Invalid values: Each field has a specific range (e.g., 0-59 for minutes). Values outside these ranges are invalid.
Incorrect separators: Fields must be separated by spaces, not commas, slashes, or other characters.
Unsupported syntax: Some schedulers support special characters like L (last day of the month) or # (nth day of the week), but the Cron Parser tool only supports standard five-field syntax.
Leading zeros: While some schedulers allow leading zeros (e.g., 05 for 5), others do not. Stick to plain numbers (e.g., 5) to avoid issues.

For example, 0 9 * * 1,2,3,4,5 is valid and runs at 9:00 AM Monday through Friday, but 0 9 * * 1-5 is also valid and achieves the same result with less typing. The Cron Parser tool will normalize the expression to the shortest valid form, so you can use whichever syntax you prefer.

For more advanced scheduling needs, consider using the Cron Expression Generator to build expressions without memorizing field order or syntax. If you’re working with JSON configurations, the JSON Validator can help ensure your cron expressions are properly formatted in configuration files. And if you need to compare two cron expressions, the Diff Checker can highlight differences between them.