100% In-Browser · Zero-Upload
Fields: 5 Standard
Explain: English & Spanish
// SCHEDULING ENGINE

Build a cron schedule. Read it back in plain language.

Pick fields visually or paste any crontab line: you get the meaning in English and Spanish, the next executions in your time zone, and precise errors instead of silent surprises.

mousy://cron/builder
Visual Builder

Schedule

Names are case-insensitive and work in English or Spanish: JAN/ENE, MON/LUN. Sunday is both 0 and 7.

mousy://cron/presets
Quick Presets

Quick presets

mousy://cron/expression
Cron Expression

Expression

* * * * *

Order: minute · hour · day of month · month · day of week.


mousy://cron/next-runs
Next Runs

Next 5 executions

—
mousy://cron/parser
Raw Parser

Cron expression

Macros supported: @yearly, @annually, @monthly, @weekly, @daily, @midnight, @hourly. Seconds blocks and @reboot are not valid here.

mousy://cron/breakdown
Field Breakdown

Field breakdown

Paste an expression to see how each field resolves.

mousy://cron/meaning
English & Spanish

Plain-language meaning

English

—


Español

—

Both languages are always shown, so the meaning travels with the schedule.

mousy://cron/next-10
Calculated Runs

Next 10 executions

—
These times are computed in your browser's time zone by advancing minute by minute. The same expression on a server in UTC — or on any machine with a different time zone or daylight-saving rules — can fire at a different wall-clock moment.

Cron syntax, without the folklore

A crontab line is five fields read left to right: 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). Every field accepts the same small grammar: * for "every value", a single number, a range 9-17, a comma list 0,30, a step */5 or a stepped range 10-50/10. Those pieces combine, so 0,15,30,45 and */15 describe the same four minutes.

The whole expression is a set intersection with one deliberate exception: minute AND hour AND month AND (day-of-month OR day-of-week). That OR is where most production incidents are born.

The day-of-month / day-of-week trap

If both day fields are restricted, Vixie cron — and therefore cronie, systemd's compatibility parser, Kubernetes CronJob and most hosted schedulers — fires when either field matches. The line 0 0 13 * 5 is not "Friday the 13th". It runs on the 13th of every month and on every Friday. To get Friday the 13th you must check the date inside the command, or use a six-field Quartz expression with a ? placeholder. To get "only Fridays", leave day-of-month as *.

Steps and their starting point

*/15 means "every 15 units starting from the minimum of the field": 0, 15, 30, 45. But 5/15 means "start at 5 and step to the end": 5, 20, 35, 50. They look almost identical and produce different schedules. When you want a predictable grid, state the range explicitly, as in 0-59/15, so a future reader cannot misread it.

Macros and portability

The @ macros are shorthand, not a different language: @daily is 0 0 * * *, @weekly is 0 0 * * 0, @monthly is 0 0 1 * * and @yearly is 0 0 1 1 *. They are supported by Linux crontab, but not everywhere else: GitHub Actions, for example, accepts five fields (and some extra aliases of its own) but not the classic macros. When a schedule has to move between platforms, the plain five fields are the safest form.

Time zones and daylight saving

Cron reads the system clock, so the same expression behaves differently on two machines in two zones. DST makes it worse: on a spring-forward day a job set for 02:30 can be skipped entirely because that wall-clock time never existed, and on a fall-back day a job inside the repeated hour can run twice. Running the scheduler in UTC removes the ambiguity — pick the zone deliberately, then leave it alone. The preview above uses your browser's zone, which is the fastest way to sanity-check a schedule but is not necessarily the zone your server uses.

Frequently Asked Questions

Why does my job run on a day I did not schedule?↓

Because both day fields are restricted, so either one triggers the run. Set day-of-month back to * when you only care about the weekday, and expect the 13th-plus-Friday behaviour whenever both are set.

Does this work for Kubernetes CronJob, GitHub Actions and systemd timers?↓

The syntax does: all of them use the classic five fields. The time zone does not. GitHub Actions schedules are always UTC, a Kubernetes CronJob uses the cluster zone unless you set spec.timeZone, and a Linux crontab uses the server's local clock. This tool previews in your browser's zone, so translate the result before you deploy.

What does a step with a named range do, such as MON-FRI/2?↓

It resolves the names first, then steps through them. MON-FRI is 1,2,3,4,5 and a step of 2 keeps 1, 3, 5 — Monday, Wednesday and Friday. The step is applied to the numeric range, not to a list of names in the order you wrote them.

How far ahead does the preview look?↓

Each next run is searched in one-minute increments with a five-year ceiling, which covers even a leap-day schedule such as 0 0 29 2 *. If a combination can never occur — day 31 restricted to February, for instance — the tool says so instead of looping.

Is my expression sent anywhere?↓

No. Parsing and next-run calculation are a few hundred lines of plain JavaScript running locally. There is no upload, no logging and no account.

Related tools

JWT decoder and signature verifier · WCAG contrast checker · All MousyTools

MousyDev

Hecho por MousyDev

Creo herramientas web que respetan tu privacidad: tus datos se procesan en tu propio navegador y nunca pasan por mis servidores.