Cron Examples Library

Browse copy-paste cron schedules — live next runs and Quartz, AWS, Kubernetes and GitHub Actions forms for each.

0 bytes uploaded

Minutes

Every 5 Minutes*/5 * * * *
Every 5 minutes
Every 30 Minutes*/30 * * * *
Every 30 minutes

Hourly

Every Hour0 * * * *
Every hour

Daily

Every Day at Midnight0 0 * * *
At 00:00

Weekly

Every Monday0 0 * * 1
At 00:00, only on Monday
Every Weekday at 9am0 9 * * 1-5
At 09:00, Monday through Friday

Monthly

First of the Month0 0 1 * *
At 00:00, on day 1 of the month
Last Day of the Monthexplainer
Classic cron cannot express this — the five-field grammar has no last-day (L) token

Special

Every 90 Minutesexplainer
Classic cron cannot express this — minute steps cannot cross the hour; install the pair 0 0-21/3 * * * and 30 1-22/3 * * *

Do it offline:$ crontab -l

How to use it

Scan the groups below — minutes, hourly, daily, weekly, monthly, special — and open the schedule whose plain-language name matches your intent; rows show their expression up front, and the two intents with no classic one-liner carry an explainer badge instead.
On the schedule page, copy the form your platform reads: the classic line for crontab, Kubernetes or GitHub Actions, the Quartz or EventBridge spelling where that dialect is required.
To adjust anything, edit the preloaded expression in the embedded tester and read the description and run preview it recomputes as you type — then copy the line it just validated.

Nine ready-made cron schedules, each on its own page: the classic five-field line, the Quartz, AWS EventBridge, Kubernetes and GitHub Actions forms beside it, and the next five run times counted in UTC from a fixed instant — the rhythm is visible before anything is installed. Each page embeds the live cron tester, preloaded. Two intents no classic one-liner can express get honest explainer pages instead of wrong answers.

Examples

*/5 * * * *

describes   Every 5 minutes
next 1      2026-08-01T00:05:00.000Z
next 2      2026-08-01T00:10:00.000Z
next 3      2026-08-01T00:15:00.000Z
next 4      2026-08-01T00:20:00.000Z
next 5      2026-08-01T00:25:00.000Z

The library's most-copied line. From the frozen instant every hit lands on a minute divisible by five, and the six-field Quartz and EventBridge rows on its page encode the same rhythm for schedulers that insist on their own spelling.

0 0 * * *

describes   At 00:00
next 1      2026-08-02T00:00:00.000Z
next 2      2026-08-03T00:00:00.000Z
next 3      2026-08-04T00:00:00.000Z
next 4      2026-08-05T00:00:00.000Z
next 5      2026-08-06T00:00:00.000Z

One page owns the whole daily intent: every day, every 24 hours and the @daily macro all name this exact line, so they appear as aliases on the midnight entry rather than as lookalike pages.

0 0 28-31 * *

describes   At 00:00, between day 28 and 31 of the month
next 1      2026-08-28T00:00:00.000Z
next 2      2026-08-29T00:00:00.000Z
next 3      2026-08-30T00:00:00.000Z
next 4      2026-08-31T00:00:00.000Z
next 5      2026-09-28T00:00:00.000Z
note        Classic cron cannot express "Last Day of the Month" in one line — these runs preview the stand-in expression "0 0 28-31 * *", not the exact intent.

August has 31 days, so the first four hits walk the 28th through the 31st — only the last is truly month-end — and the fifth is already September's 28th. The engine pins its stand-in note to every preview of this line; the explainer page adds the date guard that makes the recipe exact.

Every example on this page is executed against the same engine that powers the tool, on every build.

Gotchas worth knowing

One intent, one page — aliases fold in

Search phrasings that mean the same schedule share a single page: every 24 hours and @daily belong to the midnight entry, hourly and @hourly to the top-of-hour entry. The macros genuinely are the same schedule — the engine expands @hourly to "0 * * * *" before computing anything — so a second URL would answer nothing new.

Whose midnight? The zone changes the answer

A five-field line carries no timezone of its own: 0 0 * * * means the host's midnight in a crontab, the controller's unless a CronJob sets spec.timeZone, and always 00:00 UTC on GitHub Actions or EventBridge. Run times printed across this library are UTC; to land a job at local midnight through a DST shift, rework the hour with the cron timezone converter.

The explainer entries refuse to guess

Last day of the month and every 90 minutes have no exact five-field spelling, and the near misses fail quietly — 0 0 31 * * skips every 30-day month entirely. So those two pages lead with what works: a 28–31 stand-in plus a date guard, the two-line pair 0 0-21/3 * * * and 30 1-22/3 * * *, or rate(90 minutes) on EventBridge — each printed with its limits stated.

Common errors

cron(…) and rate(…) wrappers are AWS EventBridge syntax — paste the bare fields without the wrapper.: Raised when an EventBridge row is pasted whole into the classic tester. The wrapper is Amazon's packaging, not schedule syntax, and the six fields inside follow different day-of-week rules — so rather than unwrapping by hand, take the classic row from the same entry, or follow the dialect badge to the AWS tool.
Field 6 (day of week): "?" is Quartz syntax — L, W, # and ? do not exist in classic cron.: A pasted Quartz row parses as six classic fields — its leading number is really a seconds column — and then trips over the ? placeholder, which classic cron never adopted. Nothing is broken: the entry you copied from also prints the plain five-field form, and that one drops into anything that speaks crontab.
Field 1 (minute): step 90 is larger than its 0–59 range — only 0 ever matches.: The tempting spelling for every 90 minutes quietly degrades to hourly, because a minute step wraps inside 0–59 — yet the plain-English read-back still says Every 90 minutes, so this warning is the only honest signal. The library keeps an explainer entry for exactly this trap: the real answer takes two crontab lines or one rate() rule.

FAQ

Can the five-field examples be pasted into Kubernetes or GitHub Actions unchanged?

Yes — a CronJob's spec.schedule and a workflow's on.schedule.cron both read plain five-field cron, and each schedule page prints the line under those headings to confirm it. The caveats sit beside them: workflow schedules evaluate in UTC and never fire more often than every 5 minutes, and neither platform accepts Quartz tokens such as L.

Where do the run times under each expression come from?

From execution: the parser behind the live tester counts each schedule forward in UTC from the frozen instant 2026-08-01T00:00:00Z, and the page prints the first five hits — fixed on purpose, so the list stays stable and checkable. Edit the expression in the tester and the preview recomputes from the present moment, in the zone you choose.

What if none of the nine schedules says quite what I need?

Start from the nearest one and bend it: the embedded tester revalidates on every keystroke, reads the result back in plain English and previews upcoming runs, so a small edit is verified as you make it. Rules classic cron cannot hold — a third-Friday trigger, say — raise a dialect notice naming the syntax family, with a hand-off to the matching tool.

Nothing you paste here leaves this tab. State only ever travels in links you explicitly create.

crontab(5) — Linux manual page, man7.org · POSIX.1-2017 crontab — The Open Group Base Specifications

Last reviewed: 2026-08-05