Overview
Explains standard five-field cron expressions in plain English, validates every field, and projects the next five execution times in your browser's timezone — with quick presets, the @-shortcut family, and a saved-expression history.
How It Works
Type or paste an expression (or tap a quick preset such as Weekday work hours or Daily backup) and the translator describes the schedule in a sentence (30 2 * * * reads At 02:30.) while validation pins down any out-of-range or malformed field. The next-runs panel lists the five upcoming executions as local dates and times, recomputable with the refresh button. A field breakdown shows how many values each field allows, and Copy and Reset buttons sit beside the input.
Step-by-Step Usage Guide
- Paste your cron expression, or start from one of the five quick presets.
- Fix any field-level validation error the translator flags.
- Read the plain-English description to confirm the schedule means what you intended.
- Check the next five run times, then copy the expression into your crontab or workflow file.
Technical Specifications & Standards
Parsing follows standard Vixie cron semantics: lists, ranges, and step values in every field, named months and weekdays (with 7 aliasing to Sunday), and the day-of-month / day-of-week OR rule when both are restricted. The eight @-shortcuts from @hourly to @reboot are recognised with plain-English descriptions. Upcoming runs are projected by walking forward day by day (expanding hours and minutes only on matching days) for up to about eight years, in your browser's local timezone — there is no timezone selector, and local times skipped by a DST spring-forward are not listed.
Targeted Use Cases
- Verifying a crontab entry behaves as intended before it ships to a production server.
- Reviewing schedule triggers in GitHub Actions, Kubernetes CronJobs, or cloud schedulers that use the same five-field syntax.
- Decoding an inherited cron expression nobody on the team remembers writing.
- Confirming a monthly or weekday-restricted schedule lands on the dates you expect.
Notes & Gotchas
- Five fields only — expressions with a seconds field (six parts) are rejected with a hint, since most servers expect five.
- Run times are projected in your browser's timezone. A server in UTC can fire at different local hours, so cross-check daylight-saving edges.
- @reboot is recognised but has no predictable next run, so it is excluded from the projection.
- The scan horizon is about eight years: rare schedules such as a leap-day job (0 0 29 2 *) still show their next runs, while a schedule that never matches a real date reports no upcoming run.
Frequently Asked Questions
Does it support six-field expressions with seconds?
No. The tool validates and projects standard five-field cron, which is what vixie-cron, GitHub Actions, and Kubernetes CronJobs use.
What timezone are the next run times in?
Your browser's local timezone, without a selector — a server running in UTC may fire at different local times.
How far ahead does the projection look?
Up to roughly eight years (8 x 366 days), so yearly and leap-day schedules still find their next run. A schedule that never matches gets a no-run-found message rather than a wrong date.
Where is my expression history kept?
In your browser's localStorage (capped at twelve entries) — it never leaves your machine.