Check a cron expression and see when it runs next in any time zone.
Turn 99.9% or 99.99% into allowed downtime per month and year, and combine availability.
Open →Live Unix timestamp with bidirectional conversion, multi-timezone and multi-format output
Open →Compare local times across time zones with automatic DST handling, handy for scheduling meetings across regions.
Open →No comments yet. Be the first!
Validate a standard 5-field cron expression and get a plain-language summary plus the next 10 run times in any IANA time zone, with daylight-saving handled (times that do not exist in spring are skipped, repeated autumn times count once). It accepts month and weekday abbreviations and nicknames such as @daily, shows limits and paste-ready snippets for GitHub Actions, Vercel, Kubernetes and crontab, and can build an expression from options.
No. The tool's baseline is standard Unix/POSIX-style 5-field cron (minute hour day-of-month month day-of-week); a 6- or 7-field expression is rejected with a field-count error rather than being quietly misread. Besides numbers it accepts month and weekday abbreviations (JAN, MON) and nicknames such as @daily and @hourly. Seconds fields and Quartz ?, L, W, # are still not supported.
It is OR. That is standard Vixie cron behavior: when neither day-of-month nor day-of-week is a bare "*", the job runs if EITHER condition matches rather than requiring both. The tool's summary and the note below it spell this out.
By default your browser's local time zone; the Time zone menu lets you switch to any IANA zone (such as Asia/Taipei or America/New_York) or UTC, and the table shows both that zone's time and UTC. Server-side schedulers often run in UTC, so choose the zone your platform really uses.
When clocks jump forward, some local times do not exist (for example 02:30), so the tool skips that run and lists it under the results. When clocks fall back, a local time occurs twice and a fixed-time schedule is counted once, at its first occurrence. Platforms handle these cases differently, so for important jobs avoid the transition window or schedule in UTC.
GitHub Actions schedules have a shortest interval of 5 minutes, run in UTC by default, can be delayed under load and only fire on the default branch. Vercel reads cron expressions in UTC; on Hobby each job runs at most once a day with up to 59 minutes of timing slack, Pro and Enterprise allow per-minute, and a project can have at most 100 jobs. For a Kubernetes CronJob set the zone with .spec.timeZone; CRON_TZ or TZ inside the schedule is not supported. Pick a target platform to see these notes and a paste-ready snippet.
Yes. Open "Build an expression from options", choose every N minutes, hourly, daily, weekdays, weekly on chosen days, monthly or yearly, fill in the time and you get the expression; one click applies it to the input above so you immediately see the summary and next run times.
Runs at minute 0, at hour 9, at days-of-week 1, 2, 3, 4, 5, every month.
minute
0
hour
9
dom
*
month
*
dow
1-5
Switching platform shows that platform's limits and a ready-to-paste snippet.
Next 10 runs · UTC
Calculating…
Configuration snippet
0 9 * * 1-5 /path/to/command
0 9 * * *The baseline is standard Unix/POSIX-style 5-field cron (minute hour day-of-month month day-of-week) — the Quartz/AWS/GitHub 6–7-field variants are not supported; month/weekday abbreviations and @daily-style nicknames are expanded first and then validated.
Also supported: month and weekday abbreviations (JAN, MON) and the @daily, @hourly, @weekly, @monthly, @yearly nicknames. Seconds fields and Quartz ?, L, W, # are still not supported.
Next runs are calculated for the zone you pick with daylight-saving rules; a fixed time in the repeated fall-back hour runs once, and a time that does not exist in the spring-forward gap is skipped.
Platform rules were taken from the GitHub, Vercel and Kubernetes documentation (verified 2026-10-20); platforms can change, so follow their docs.