A cron next run calculator answers the one question a cron expression is genuinely bad at communicating: when will this actually fire? The five-field syntax is compact and precise, but it is written for a scheduler, not for a human reading a pull request at four in the afternoon. */15 9-17 * * 1-5 is unambiguous to a daemon and near-opaque to a reviewer. This tool parses the expression the same way a standard cron implementation does and prints the next ten fire times as ordinary dates, so you can confirm the schedule matches the intent before it ships.
Arb Digital's engineering team keeps this page open during deployment reviews, because a mistyped cron field is one of the quietest failure modes in production. Nothing errors. Nothing alerts. The job simply runs a hundred times more often than intended, or once a year instead of once a day, and nobody finds out until the invoice or the incident arrives. Everything here runs in your browser — no expression you paste leaves the page.
What This Cron Next Run Calculator Does
Type a five-field expression and the parser expands each field into the explicit set of values it permits, then walks forward from your chosen start time looking for the next moments where minute, hour, month and the day rule all match simultaneously. The first match is the headline result. The next ten are listed in full, with the weekday named, because "2026-09-01 02:30" tells you far less than "Tuesday, 1 September 2026 at 02:30".
The four supporting figures describe the shape of the schedule rather than a single moment. Runs in the next 24 hours and runs in the next 7 days are counted by the same scan, and they are the fastest way to catch an accidental over-schedule: if you expected a nightly job and the counter reads 1,440, you have written a minute field of * where you meant a specific minute. The average gap is measured across the ten runs shown, so an irregular schedule reports an honest average rather than a fictional uniform interval, and the final tile counts down to the first fire time.
The parser accepts everything in the standard field syntax: the wildcard *, single values, comma lists like 1,15, ranges like 9-17, step values like */15 and 0-30/10, three-letter month names such as JAN and DEC, three-letter weekday names such as MON and SUN, and 7 as an alias for Sunday alongside 0. An invalid field is reported as an explicit parse error naming the field, rather than being silently coerced into something that runs at the wrong time.
How to Use It
- Paste the expression. Five fields separated by spaces: minute, hour, day of month, month, day of week. Extra spaces between fields are fine.
- Set the timezone. Choose UTC if the job runs on a server configured for UTC, which is the common default for cloud instances and containers. Choose local if the machine uses your own clock.
- Choose a start point. The field defaults to now. Change it to test how a schedule behaves across a month boundary, a leap day, or a specific release window.
- Click Show next 10 runs. The hero gives the immediate next fire time, the four tiles describe frequency, and the list below shows all ten with weekday names.
- Copy the schedule into the pull request or the runbook, so the reviewer reads dates rather than re-deriving them from the syntax.
How the Next Run Is Calculated
Each of the five fields is expanded into a sorted set of permitted integers. Minute allows 0 to 59, hour 0 to 23, day of month 1 to 31, month 1 to 12, and day of week 0 to 6 with Sunday at both 0 and 7. A step value is applied over whatever range precedes it: */15 in the minute field means every value from 0 to 59 taken in steps of 15, which yields 0, 15, 30 and 45 — note that this is aligned to the top of the hour, not to the moment you deploy. 10-40/10 yields 10, 20, 30 and 40, and stops there rather than continuing past the end of its range.
Once the sets exist, the search is a walk rather than a formula, because the day rule depends on the calendar. The scan advances a day at a time, testing whether that date's month is in the month set and whether the date satisfies the day rule described in the next section. Days that fail are skipped whole. On a day that qualifies, every permitted hour and minute pair is generated in ascending order and any pair at or after the start time is a run. The walk stops once ten runs are collected, or after several years of calendar if the expression can never match — which is how an impossible schedule like 0 0 30 2 *, the thirtieth of February, is caught and reported instead of hanging.
This walk-and-test approach is deliberate. It handles month lengths, leap years and the interaction between the two day fields correctly by construction, because it asks the calendar rather than trying to compute an interval. The field semantics themselves follow the behaviour documented in the crontab(5) manual page, which is the reference implementation most schedulers are measured against.
The Day-of-Month and Day-of-Week OR Rule
This is the single most misread rule in cron, and it is the reason this calculator exists. When both the day-of-month field and the day-of-week field are restricted — meaning neither is * — cron matches a day if either field matches. It does not require both. Every other pair of fields in the expression is combined with AND, so the exception is genuinely surprising, and it is not something you can infer from the syntax. The OR behaviour is standardised, not an implementation quirk: it is specified in the POSIX crontab specification, which is why every mainstream scheduler reproduces it.
The classic demonstration is 0 0 13 * 5. Read casually, that looks like "midnight on Friday the 13th". It actually means midnight on the 13th of every month, plus midnight on every Friday — roughly sixty runs a year instead of one or two. Paste it above and the seven-day counter tells you immediately. The inverse mistake is just as common: 0 3 1 * 1 intended as "the first Monday of the month" runs on the 1st of every month and on every Monday, which is neither what was meant nor anything useful.
The rule only applies when both day fields are restricted. If day-of-week is *, only the day-of-month matters. If day-of-month is *, only the weekday matters. That is why 0 0 * * 5 is the correct way to say "midnight every Friday" — leave the other day field as a wildcard and the OR never engages. Standard cron has no way to express "the first Monday of the month" in a single expression at all; the conventional workaround is 0 3 1-7 * 1, which fires on any of the first seven days or any Monday, combined with a guard inside the script that exits unless today is genuinely both.
Timezone Is an Assumption, Not a Property
A cron expression contains no timezone information whatsoever. The five fields are bare numbers; the clock they are read against belongs entirely to the machine running the daemon. This calculator therefore has to assume one, and it tells you which: by default it uses your browser's local timezone, and the dropdown switches it to UTC. The subtitle under the headline result always states the assumption in force, including the current offset, so a screenshot of this page is never ambiguous.
Get this wrong and the failure is subtle rather than loud. A nightly report scheduled at 0 2 * * * on a server set to UTC runs at 2am UTC, which is 9pm the previous evening in New York and 7am in Karachi. The job succeeds every time. It simply covers the wrong day's data, and the discrepancy usually surfaces weeks later as a reconciliation problem. If you are converting a schedule between the zone your team thinks in and the zone the server is set to, our timezone converter handles the offset, and the Unix timestamp converter is useful when the log lines you are checking against are recorded as epoch seconds.
Daylight saving adds a second layer. On a server running local time, the spring-forward transition skips an hour of wall clock entirely, so a job scheduled inside the skipped hour may not run that day, and the autumn transition repeats an hour, so the same job may run twice. Different implementations resolve this differently and none resolve it invisibly, which is the practical reason most production infrastructure is set to UTC and left there. Transition dates come from the IANA time zone database, which changes several times a year as governments legislate, so a server that is not kept current can be an hour out on schedules that were correct when they were written. Note that this calculator's local mode derives times from the browser's own calendar, so it inherits the same transition edge cases rather than pretending they are not there.
Reading Steps, Ranges and Lists Correctly
Step syntax describes divisions of a range, not an interval from the moment of deployment. */20 in the minute field fires at :00, :20 and :40 of every hour. It does not mean "twenty minutes after this job last ran", and it never drifts. That distinction matters when a job takes longer than its own interval: if a task scheduled */5 takes seven minutes, cron will start a second copy while the first is still running. Cron has no concurrency control of any kind, and expecting it to wait is one of the most expensive assumptions in scheduling. The standard remedy is a lock file or a wrapper such as flock inside the command itself.
Steps applied to an explicit range stop at the end of that range: 9-17/2 in the hour field gives 9, 11, 13, 15 and 17, then stops, even though hour 19 would also be two steps on. Lists mix freely with ranges and steps, so 0,30 9-12,14-17 * * 1-5 is a perfectly valid half-hourly office-hours schedule with a lunch gap. The one thing that catches people is the interaction between a step in the minute field and a restricted hour field — */30 9 * * * runs twice, at 09:00 and 09:30, not every thirty minutes all day.
What Standard Cron Cannot Express
This parser implements the standard five-field syntax and deliberately refuses anything outside it, because accepting an extension and guessing at its meaning would produce confidently wrong times. Several widely-used extensions are not part of that standard. The special strings @reboot, @daily, @hourly and their siblings are shorthands supported by many daemons but are not field expressions; only @reboot has no fixed-time equivalent at all, since it depends on when the machine happens to start. The Quartz scheduler used across the Java ecosystem takes six or seven fields, with seconds in front and an optional year at the end, and adds L for last, W for nearest weekday, and # for the nth weekday of the month. AWS EventBridge uses a six-field variant of its own and requires ? in one of the two day fields.
If your expression starts with a seconds field, or contains L, W, # or ?, it is not a standard five-field expression and the times below would not describe it. The parser will tell you so rather than assume. That refusal is the honest behaviour: a scheduling tool that silently reinterprets your syntax is worse than no tool.
Building an Expression Versus Reading One
These are opposite jobs and we publish a separate tool for each. Our cron expression generator goes forwards: you describe the schedule you want in plain controls and it writes the five fields for you. This page goes backwards: you already have an expression — inherited from a legacy crontab, copied from a Stack Overflow answer, or generated by a framework — and you need to know what it actually does before trusting it. Use the generator when you are authoring, and this parser when you are reviewing, debugging, or auditing a crontab someone else wrote.
Generate an expression, paste it here, and confirm the ten dates match your intent. That round trip catches the OR rule, the step alignment and the timezone assumption in about fifteen seconds — considerably faster than discovering any of them from production logs.
Auditing a Crontab You Inherited
Legacy crontabs accumulate. A file with thirty entries typically contains several that overlap and at least one that runs far more often than anyone realises. Working through them here, one expression at a time, surfaces the outliers quickly: sort your entries by the runs-per-day figure and the mistakes announce themselves. Two habits make the audit stick. Record the intended schedule in a plain-English comment above every line, because the expression alone will not survive a handover. And check the environment the job runs in — cron uses a minimal environment and a short PATH, which is why a script that works interactively so often fails silently under cron. Our env file parser lays out an environment file as structured data so you can see exactly what is defined.
Arb Digital builds and maintains web applications with monitored background jobs, documented schedules, and alerting that tells you when a task did not run — not three weeks later.
Web Development Services Talk To Our TeamCommon Mistakes to Avoid
- Reading the two day fields as AND — when both are restricted they combine with OR, which turns "Friday the 13th" into roughly sixty runs a year.
- Assuming the expression carries a timezone — it does not. The daemon's own clock decides, and on most cloud servers that clock is UTC.
- Treating
*/nas an interval since the last run — it is a division of the range, always aligned to the top of the hour, and it never drifts to fit a long-running job. - Expecting cron to prevent overlapping runs — it has no concurrency control at all. If the job outlives its interval, copies stack up until you add a lock.
- Pasting a six-field or Quartz expression into a five-field parser — the seconds field shifts every other field one position left and every predicted time will be wrong.
Related Free Tools From Arb Digital
Author a new schedule with the cron expression generator, convert a server time to your own with the timezone converter, decode epoch values from your logs with the Unix timestamp converter, measure the span between two runs with the date difference calculator, or exclude weekends from a reporting window with the business days calculator. The full free online tools hub lists every developer utility we publish.
Frequently Asked Questions
By default it uses your browser's local timezone, and the dropdown switches it to UTC. A cron expression itself carries no timezone, so the times shown are only correct if the assumption matches the clock on the machine running the job.
Because when both the day-of-month and day-of-week fields are restricted, cron combines them with OR rather than AND. That expression fires on the 13th of every month and on every Friday, not only on Friday the 13th.
The generator builds an expression from a schedule you describe. This page does the reverse: it parses an expression you already have and shows the next ten times it will fire, which is what you need when reviewing or debugging someone else's crontab.
No. Those are extensions outside the standard five-field syntax, used by shorthand aliases and by schedulers such as Quartz. The parser reports them as unsupported rather than guessing, because a wrong prediction is worse than none.
Every minute value from 0 to 59 in steps of 15, which is 0, 15, 30 and 45. It is aligned to the top of the hour and is not an interval measured from when the job was deployed or last finished.
No. Cron has no concurrency control and will start a new process on schedule regardless. Long-running jobs need a lock file or a wrapper such as flock to prevent copies from stacking up.
No. The parsing and the date arithmetic both run entirely in your browser. Nothing is uploaded or logged, and closing the tab discards whatever you typed.
Predicted times assume the scheduling machine's clock matches the timezone selected above; daylight saving transitions are handled differently by different cron implementations.
