Translate cron to plain English

In order: 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). An asterisk means "every value". So "0 9 * * 1-5" is minute 0, hour 9, any day of the month, any month, Monday through Friday — 09:00 on weekdays.

Because standard cron combines day-of-month and day-of-week with OR, not AND. When both fields are restricted, the job runs if EITHER matches. "0 9 1-7 * 1" therefore fires on the 1st through 7th of every month AND on every Monday. To get only the first Monday, leave one field as * and guard the job itself — for example schedule "0 9 1-7 * *" and start the script with [ "$(date +%u)" = "1" ] || exit 0.

None of its own. A cron expression is just numbers; the scheduler decides which timezone to interpret them in. Traditional crontab uses the system timezone and honours a TZ or CRON_TZ variable. Kubernetes CronJobs take a timeZone field. Vercel Cron Jobs and GitHub Actions always run in UTC. If a schedule has to fire at a specific local time, set the timezone explicitly or convert to UTC yourself.

Not consistently. A step restarts at the beginning of each field range, and 7 does not divide 60. "*/7 * * * *" fires at minutes 0, 7, 14, 21, 28, 35, 42, 49, and 56, then again at minute 0 of the next hour — an 11-minute gap. Only steps that divide their field evenly (2, 3, 4, 5, 6, 10, 12, 15, 20, 30 for minutes) give a truly regular interval.

Standard cron cannot express it. Quartz-based schedulers have an L specifier, but crontab, Kubernetes, GitHub Actions, and Vercel do not support it. The portable approach is to run daily and exit early unless tomorrow is the 1st: schedule "0 0 * * *" and begin the job with [ "$(date -d tomorrow +%d)" = "01" ] || exit 0. Scheduling "0 0 28-31 * *" instead will fire up to four times a month, not once.

They are convenient but not portable. These macros come from Vixie cron and are understood by traditional crontab, but many hosted schedulers — including Vercel Cron Jobs, Kubernetes CronJobs, and GitHub Actions — reject them and require five explicit fields. @daily is "0 0 * * *", @hourly is "0 * * * *", @weekly is "0 0 * * 0", @monthly is "0 0 1 * *", and @yearly is "0 0 1 1 *". Using the expanded form always works.

They are Quartz extensions, not standard cron. L means "last" (last day of the month, or last given weekday), W means "nearest weekday", # selects the nth weekday of the month (6#3 is the third Friday), and ? is a placeholder meaning "no specific value". Java Quartz and Spring support them; Unix crontab, Kubernetes, GitHub Actions, and Vercel do not. This tool detects them and reports that it cannot evaluate them rather than guessing at run times you would not actually get.

One minute. The finest field is minutes, so "* * * * *" — 1,440 runs a day — is the maximum frequency. Six-field expressions that add seconds at the front exist in Quartz and some libraries such as node-cron, but standard crontab rejects them. For sub-minute work, run a long-lived process with its own timer instead of a cron schedule.

Yes, and it is built for that. There is a JSON API at /api/v1/, an MCP server at /api/mcp with explain_cron, next_cron_runs, and build_cron tools, an OpenAPI document at /.well-known/openapi.json, and a machine-readable index at /llms.txt. Every page is also available as markdown at the same URL with an Accept: text/markdown header. The free allowance is 250 calls per day per caller; past that endpoints return HTTP 402 with x402 payment requirements.