Below are the cron schedules people actually look up, each with a plain-English reading and the next run times. Every description and run time on this page was generated by the same parser the Cron Expression Generator uses, counting from Thursday, October 15, 2026 at 00:00 UTC.
How to read a cron expression
The five fields, left to right:
| Field | Allowed values | Example |
|---|---|---|
| Minute | 0–59 | 30 = at minute 30 |
| Hour | 0–23 | 9-17 = 9:00 through 17:00 |
| Day of month | 1–31 | 1 = the 1st |
| Month | 1–12 or JAN–DEC | */3 = every third month |
| Day of week | 0–6 or SUN–SAT (7 = Sunday too) | 1-5 = Monday to Friday |
Four symbols do most of the work: * means every value, , separates a list (1,15), - makes a range (1-5) and / sets a step (*/15 is every 15th value starting from the first).
The cheat sheet
| Expression | Meaning | Next two runs (UTC) |
|---|---|---|
* * * * * | Every minute | Thu, Oct 15, 00:01 UTC; Thu, Oct 15, 00:02 UTC |
*/5 * * * * | Every 5 minutes | Thu, Oct 15, 00:05 UTC; Thu, Oct 15, 00:10 UTC |
*/15 * * * * | Every 15 minutes | Thu, Oct 15, 00:15 UTC; Thu, Oct 15, 00:30 UTC |
0 * * * * | Every hour | Thu, Oct 15, 01:00 UTC; Thu, Oct 15, 02:00 UTC |
0 */6 * * * | On the hour, every 6 hours | Thu, Oct 15, 06:00 UTC; Thu, Oct 15, 12:00 UTC |
0 0 * * * | At 00:00 | Fri, Oct 16, 00:00 UTC; Sat, Oct 17, 00:00 UTC |
30 2 * * * | At 02:30 | Thu, Oct 15, 02:30 UTC; Fri, Oct 16, 02:30 UTC |
0 9 * * 1-5 | At 09:00, Monday through Friday | Thu, Oct 15, 09:00 UTC; Fri, Oct 16, 09:00 UTC |
0 9-17 * * 1-5 | Every hour, between 09:00 and 17:00, Monday through Friday | Thu, Oct 15, 09:00 UTC; Thu, Oct 15, 10:00 UTC |
*/30 9-17 * * 1-5 | Every 30 minutes, between 09:00 and 17:59, Monday through Friday | Thu, Oct 15, 09:00 UTC; Thu, Oct 15, 09:30 UTC |
0 0 * * 0 | At 00:00, only on Sunday | Sun, Oct 18, 00:00 UTC; Sun, Oct 25, 00:00 UTC |
0 0 1 * * | At 00:00, on day 1 of the month | Sun, Nov 1, 00:00 UTC; Tue, Dec 1, 00:00 UTC |
0 0 1 1 * | At 00:00, on day 1 of the month, only in January | Fri, Jan 1, 00:00 UTC; Sat, Jan 1, 00:00 UTC |
0 0 1 */3 * | At 00:00, on day 1 of the month, every 3 months | Fri, Jan 1, 00:00 UTC; Thu, Apr 1, 00:00 UTC |
0 8 1-7 * 1 | At 08:00, between day 1 and 7 of the month, and on Monday | Mon, Oct 19, 08:00 UTC; Mon, Oct 26, 08:00 UTC |
The last row is a trap, covered next.
Pitfall 1: day of month OR day of week
When both the day-of-month and day-of-week fields are restricted, standard Unix cron runs the job when either matches. So 0 8 1-7 * 1 does not mean "the first Monday of the month". It means "days 1 to 7, and also every Monday". From October 15 its next runs are Mon, Oct 19, 08:00 UTC; Mon, Oct 26, 08:00 UTC; Sun, Nov 1, 08:00 UTC; Mon, Nov 2, 08:00 UTC, which includes Mondays well after the first week.
Two ways to get the first Monday:
- Use the
#extension if your scheduler supports it:0 8 * * 1#1runs Mon, Nov 2, 08:00 UTC; Mon, Dec 7, 08:00 UTC. Classic Linux cron and GitHub Actions don't support it. - Schedule
0 8 * * 1and exit early in the script unless the date is 7 or less, for example[ "$(date +\%d)" -le 07 ] && ./job.shin a crontab line (the%must be escaped there).
Similarly, 0 9 * * 5L is the last Friday of the month on schedulers that support L; next runs: Fri, Oct 30, 09:00 UTC; Fri, Nov 27, 09:00 UTC.
Pitfall 2: which time zone?
A cron expression has no time zone of its own. The scheduler decides:
- Linux cron uses the server's system zone; cronie also reads a
CRON_TZ=line in the crontab. - GitHub Actions runs
scheduletriggers in UTC by default (GitHub docs). - Kubernetes CronJobs use the controller's zone unless you set
spec.timeZone(Kubernetes docs).
The same expression lands at very different local times. Here is 0 9 * * 1-5 evaluated in three zones:
| Zone | Next run, shown in UTC |
|---|---|
| UTC | Thu, Oct 15, 09:00 UTC |
| America/New_York | Thu, Oct 15, 13:00 UTC |
| Asia/Tokyo | Fri, Oct 16, 00:00 UTC |
If a job must run at a specific UTC instant, say for an API with a daily reset, schedule it in UTC. If it must run at a local business hour, schedule it in that local zone and accept the daylight saving behavior below. To translate a run time between zones or check a logged epoch value, the Unix timestamp converter helps.
Pitfall 3: daylight saving time
In a zone with daylight saving, local times between roughly 1:00 and 3:00 are risky. On the spring-forward day the 2:00–3:00 hour doesn't exist; on the fall-back day the 1:00–2:00 hour happens twice. How a scheduler handles that varies. With the parser used here, in America/New_York:
30 2 * * *around March 14, 2027 runs: Sun, Mar 14, 03:30 EDT; Mon, Mar 15, 02:30 EDT. The 2:30 that doesn't exist becomes 3:30.30 1 * * *around November 7, 2027 runs: Sun, Nov 7, 01:30 EDT; Mon, Nov 8, 01:30 EST. It runs once, even though 1:30 happens twice.
Classic Vixie cron has its own adjustment rules, and other schedulers may skip or double-run. The safe habits: keep critical jobs out of the 1:00–3:00 local window, or schedule them in UTC. The same mismatch causes trouble for people too; see finding a meeting time across time zones.
A quick checklist before you deploy
- Paste the expression into the generator and read the plain-English description.
- Pick the time zone your scheduler really uses and check the next ten runs.
- If both day fields are set, confirm you want the OR behavior.
- Check whether your scheduler accepts extensions such as
L,#, names (MON) or macros (@daily) before using them. - In a crontab, escape any
%in the command and use absolute paths, because cron runs with a minimal environment.
The Developer Toolkit also has a cron builder alongside YAML, regex and .env tools if you're editing a config file with several of these at once.