Cron Explainer

Read a schedule in plain English and see its next runs — Linux cron, Kubernetes, GitHub Actions, Quartz/Spring, AWS EventBridge and systemd timers.

Free · no sign-up · updated

Runs entirely in your browser. Nothing you enter leaves this page.

requests since opened: 0
Verify it yourself

This page is served with a security policy your browser enforces: it cannot open connections or load anything from other sites — not even to us.

  1. Open your browser’s developer tools (F12, or ⌥⌘I on Mac) → Network tab, then use the tool. No new requests appear.
  2. Or disconnect from the internet after the page loads — the tool keeps working, because it never needed the network.
  3. See the rule itself: in the Network tab, select this page’s document → Response Headers → content-security-policy contains connect-src 'none' and no 'unsafe-inline' for scripts.
  4. Press Test the lock: the page tries a harmless request and the browser blocks it (the Console shows the refusal).

tools v0.9.1 · build 0efa119

How to use
  1. Pick where the schedule runs — each system reads cron differently.
  2. Paste the expression to read it in English, field by field.
  3. Check the next runs in the right time zone.

Where does this schedule run?

crontab(5): minute hour day-of-month month day-of-week

“At 09:00 on Monday through Friday.”

field by field

Minute00
Hour99
Day of month*every value
Month*every value
Day of week1-5Mon, Tue, Wed, Thu, Fri

next runs in

    Times inside a daylight-saving gap are skipped here; some schedulers run them late instead.

    Same five fields, different rules

    Standard cron reads minute, hour, day of month, month and day of week. Quartz and Spring add seconds in front and an optional year, and require ? in one of the two day fields. AWS EventBridge uses six fields inside cron( ), also with ?, and always runs in UTC. systemd timers use a different calendar syntax altogether. Kubernetes and GitHub Actions use standard five-field cron — GitHub always in UTC, and runs can start late when its runners are busy.

    Mistakes that look right

    If both day fields are set in standard cron, the job runs when either matches, not both: “0 9 13 * 5” runs on every 13th and every Friday. A step restarts each hour: */7 in the minute field runs at 0, 7 … 56 and then 0 again, a four-minute gap. And 0 0 31 * * never runs in months with fewer than 31 days.

    Daylight saving time

    When clocks go forward, times inside the skipped hour do not exist; when they go back, an hour happens twice. Schedulers handle this differently — some skip, some run late, some run twice — so jobs that must run exactly once belong in UTC. The next-runs list uses the time zone you choose and shows the real local times around each change.

    Common questions

    What does */5 mean in cron?

    “Every 5th value”: in the minute field, */5 runs at minutes 0, 5, 10 and so on. A range with a step, such as 10-30/5, runs at 10, 15, 20, 25 and 30.

    Why does my cron job run on unexpected days?

    In standard cron, if both day-of-month and day-of-week are set, the job runs when either matches. The explainer warns about this.

    Which time zone does cron use?

    The scheduler’s: the server’s time zone for crontab, .spec.timeZone for Kubernetes, and always UTC for GitHub Actions and EventBridge rules.

    Known limitations
    • systemd “~” (days from the end of the month) isn’t supported yet.
    • EventBridge rate() has no fixed start, so next runs can’t be listed.
    • Times inside a daylight-saving gap are skipped.
    • Browser extensions can read any page — use a private window for sensitive data. How the lock works

    Related reading on CipherMind

    Standards & references