RunLocalTools

Cron Expression Parser

Paste a cron expression and get a plain-English translation of what it actually does, plus a list of the next several times it will run — computed locally, no server-side scheduling library required.

Why cron syntax is so easy to get subtly wrong

Cron expressions pack five (sometimes six) fields into a compact string, and the ordering — minute, hour, day of month, month, day of week — is unintuitive enough that even experienced developers routinely second-guess themselves before deploying a scheduled job. The stakes for getting it wrong range from mildly annoying (a report runs at the wrong hour) to genuinely costly (a billing job runs twice a day instead of once, or a cleanup script hits at peak traffic instead of 3am). The interaction between “day of month” and “day of week” is a particular common source of mistakes, since providing both fields as anything other than a wildcard doesn’t work the way most people initially assume — most cron implementations treat this as an OR condition, not an AND.

How to use it

  1. Paste or type your cron expression into the input field.
  2. Get an immediate plain-English breakdown, field by field, explaining exactly what each part means (“at minute 30,” “every day,” “only in December,” etc.) alongside the combined full-sentence translation.
  3. See a list of the next 5-10 actual run times based on the current date, so you can sanity-check the schedule against real calendar dates rather than just trusting the abstract translation.
  4. Switch the reference timezone to check how the schedule lines up in UTC versus your local time, which matters if the system running the cron job operates in a different timezone than you do.
  5. Use reverse mode to build a cron expression from a plain-English description or a visual field-by-field picker, if you’re starting from “I want this to run every weekday at 9am” rather than already having an expression to decode.
  6. A validity checker flags syntax errors immediately, rather than letting an invalid expression silently fail once deployed.

Common situations this solves

  • Verifying a scheduled job’s timing before deploying it, especially for cron expressions inherited from documentation, Stack Overflow, or a previous engineer, where trusting an unverified expression is a real risk.
  • Debugging why a scheduled task ran at an unexpected time, often traced back to a timezone mismatch between where the expression was written and where the server actually executes it.
  • Understanding an unfamiliar cron expression found in an existing codebase’s deployment config, CI pipeline, or crontab file, without needing to mentally parse five cryptic fields.
  • Building a new cron expression from scratch for a common scheduling need (every hour, every weekday, first of the month) using the reverse builder instead of writing the syntax by hand.
  • Predicting the next several execution times to plan around a scheduled job, such as confirming a maintenance window won’t overlap with a scheduled batch process.

Frequently asked questions

Why does my cron expression with both a day-of-month and day-of-week value run more often than I expected?

This is the single most common cron mistake — when both the day-of-month and day-of-week fields are set to something other than * (wildcard), most standard cron implementations treat the condition as OR, not AND, meaning the job runs if either condition is satisfied, not only when both are. If you only want one condition to apply, set the other field back to *.

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

A bare * means “every value” — so in the minute field, that’s every single minute. */5 means “every 5th value starting from 0” — so minutes 0, 5, 10, 15, and so on. This step syntax is a common shorthand for recurring intervals rather than listing out every individual value manually.

Does this tool account for daylight saving time transitions?

Yes, the “next run times” projection accounts for DST shifts in the selected timezone, which matters because a cron job scheduled for, say, 2:30am can behave unexpectedly on the specific days DST transitions happen (that time either not existing or existing twice, depending on the direction of the shift).

Are all cron implementations exactly the same syntax?

Mostly, but not entirely — some systems (like some CI/CD platforms) support a 6-field format that adds seconds, and some support non-standard shortcuts like @daily or @hourly as aliases for common expressions. This tool defaults to standard 5-field Unix cron but supports toggling to the 6-field and common-alias variants to match your specific platform.

Can I use this to schedule something for “the last day of the month,” since standard cron doesn’t support that directly?

Standard cron syntax genuinely can’t express “last day of the month” directly, since it has no concept of a month’s variable length — this is a real limitation of the format itself, not something this tool can work around. The common practical workaround is scheduling for day 28-31 with additional logic in the job itself to check if tomorrow is the 1st, which this tool’s plain-English explanation will flag as a caveat if it detects that pattern.