Crontab Generator & Cron Expression Builder

What Is a Cron Expression?

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

Key Features

Cron Variants & Schedulers

Cron Expression Examples

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

How to Build a Cron Expression

1. 1

   Type or paste a cron expression

   Enter a five-field cron expression in the input above (e.g., `*/15 * * * *`). The tool parses and validates as you type — green check for valid, red error with field name for invalid. Macros like `@daily`, `@hourly`, etc. are also accepted.

2. 2

   Or tweak the five field inputs

   Don't memorize the field order — edit Minute, Hour, Day-of-month, Month, or Day-of-week individually using the labeled inputs. The full expression at the top updates automatically. Use `*` for wildcards, `*/N` for steps, `a-b` for ranges, and `1,3,5` for lists.

3. 3

   Pick a preset to jump-start

   Tap any preset chip (Every 15 minutes, Weekdays at 9 AM, etc.) to load a common schedule, then tweak the fields to fit your exact need. Eleven presets cover the patterns you'll actually use in production.

4. 4

   Verify the next-run preview

   Look at the five upcoming run datetimes — switch between Local and UTC to confirm the schedule fires when you intend. This is the single most reliable way to catch the POSIX day-of-month / day-of-week OR gotcha before it bites you in production.

5. 5

   Copy and paste into your scheduler

   Click Copy to grab the expression. Paste into your crontab, systemd timer, GitHub Actions `cron:`, AWS EventBridge, Kubernetes CronJob `schedule`, or any cron-compatible scheduler. Don't forget to verify the target scheduler's timezone — see the Best Practices section below.

Common Cron Mistakes

# Intended: "first Friday of the month"
0 0 1-7 * 5
# Actually: fires on days 1-7 of the month OR every Friday — both conditions

# Use wrapper for true AND semantics
0 0 * * 5  [ $(date +\%d) -le 7 ] && /your-script
# OR drop one condition and accept the looser schedule

# Written by US East dev, deployed to UTC server
0 9 * * *  /your-report.sh
# Fires at 9 AM UTC = 4 AM US East — not what the dev meant

# Lock timezone, or write in UTC explicitly
CRON_TZ=America/New_York
0 9 * * *  /your-report.sh

# Intended: every 15 minutes
15 * * * *
# Actually: once per hour, at minute 15 (4 runs/hour less than intended)

# Correct
*/15 * * * *
# Every 15 minutes: minute 0, 15, 30, 45 of every hour

# Quartz 6-field copied into Linux crontab
0 0 9 * * 1-5
# Linux reads: minute=0, hour=0, dom=9, month=*, dow=1-5
# = midnight on days 9 in months matching weekdays — chaos

# POSIX 5-field, drop the seconds
0 9 * * 1-5
# = weekdays at 9:00 AM

# February 30 or 31 — never runs
0 0 30 2 *
0 0 31 2 *
# Parses but no schedule ever fires

# Use day-of-week 'last weekday of February' pattern via script
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /your-script

# Quartz: 'last Friday of the month' — invalid in POSIX
0 0 ? * 6L *

# POSIX wrapper script approach for last-Friday
0 0 25-31 * 5  /your-script
# Run on Friday between the 25th-31st of any month

Common Use Cases

Linux Crontab Jobs

Build and verify entries for `/etc/crontab`, `/etc/cron.d/*`, or per-user `crontab -e` files. Use the next-run preview to confirm the schedule lands at the right time in your server's configured timezone before saving.

Kubernetes CronJob Schedules

Generate the `spec.schedule` field for a Kubernetes CronJob. Kubernetes 1.27+ also supports `spec.timeZone` — use the UTC toggle to design your schedule in UTC, then explicitly set `timeZone` to avoid the worker node's local time.

GitHub Actions Scheduled Workflows

Build the `cron:` entry under `on.schedule`. GitHub Actions runs in UTC always — toggle the preview to UTC to confirm your schedule. Avoid intervals shorter than 15 minutes; GitHub's scheduler skips short-interval jobs under load.

AWS EventBridge Rules

Compose the cron expression for an EventBridge scheduled rule. Note: AWS uses Quartz-style six-field syntax with `?` for day-of-week — this tool emits POSIX five-field, which you'll need to convert by prefixing seconds (`0`) and replacing the `*` in either day field with `?`.

GitLab CI Scheduled Pipelines

Verify the cron expression for a scheduled CI pipeline in GitLab. GitLab uses POSIX five-field syntax — what this tool emits — and a UI date picker, but the cron form gives you finer control for non-standard intervals.

Cloudflare Workers Cron Triggers

Build the `[triggers.crons]` entry in `wrangler.toml`. Cloudflare uses POSIX five-field syntax. Minimum interval is one minute; the worker runs at UTC. Use the preview to verify the trigger fires within your expected window.

Node.js node-cron Schedules

Build expressions for the `node-cron` library, which supports both five-field POSIX and an optional leading seconds field. Stick to five fields unless you specifically need sub-minute precision — six-field expressions don't port to Linux crontab.

Code Review and Documentation

Paste a cron expression from a PR or runbook to instantly see what it does — no more guessing at `30 7 * * 1-5` or pulling out a reference card. The plain-English description is also great for inline comments and README files.

Cron Syntax Reference

Field Order: M H D M W

Minute (0-59), Hour (0-23), Day-of-month (1-31), Month (1-12), Day-of-week (0-6, 7 also = Sunday). Mnemonic: "My Hat Doesn't Match Wendy's". The day-of-week field accepts both numeric (0-6) and named (SUN-SAT, case-insensitive) tokens.

Operators

`*` = any value; `,` = list separator (`1,3,5`); `-` = range (`1-5`); `/` = step (`*/15`, `5/10`); names: JAN-DEC for month, SUN-SAT for day-of-week (case-insensitive).

Macros (Aliases)

`@yearly` = `0 0 1 1 *`; `@annually` = `0 0 1 1 *`; `@monthly` = `0 0 1 * *`; `@weekly` = `0 0 * * 0`; `@daily` = `0 0 * * *`; `@midnight` = `0 0 * * *`; `@hourly` = `0 * * * *`. `@reboot` is a special non-schedule (runs only at boot) and is rejected with an explanatory error.

POSIX Day Semantics (OR Rule)

When BOTH day-of-month and day-of-week are restricted (neither is `*`), the schedule runs when EITHER matches — OR semantics. When only one is restricted, that one decides. When both are `*`, every day matches. This OR rule applies to vixie cron, BSD cron, and most POSIX implementations; Quartz uses `?` to disambiguate AND vs OR.

Six-Field Mode (Quartz-Lite)

If your input has six space-separated tokens, the tool treats the first as a seconds field (0-59). Useful for Quartz, Spring `@Scheduled(cron=...)`, and node-cron. NOT portable to Linux crontab or POSIX schedulers — they'd treat your seconds as minutes and shift everything by one position.

Step Operator Anchoring

`*/N` is anchored to the field's lowest value: `*/15` in minute = `0,15,30,45`, not "every 15 starting now". With a non-wildcard base: `5/15` in minute = `5,20,35,50`. Step values that don't divide the field range evenly will skip near the wraparound — this is correct, not a bug.

Validation Boundaries

minute ∈ [0,59], hour ∈ [0,23], day-of-month ∈ [1,31], month ∈ [1,12], day-of-week ∈ [0,7]. Out-of-range values produce a field-level error. The day-of-month is NOT validated against the month (`0 0 31 2 *` parses fine but never matches because Feb has no day 31 — the next-run preview will show "No upcoming runs").

Quartz Operators Rejected

POSIX cron does not support Quartz's `?` (no specific value), `L` (last), `W` (nearest weekday), or `#` (nth weekday). This tool rejects them with a clear "Quartz operators not supported" message rather than silently parsing them as invalid POSIX. For Quartz schedules, use a Quartz-aware tool or the Spring scheduler instead.

Year-Cap on Next-Run Search

The next-run computation searches up to 4 years forward; expressions that match less often than that (e.g., "Feb 29" patterns) will show "No upcoming runs in the next 4 years". This is by design to avoid unbounded iteration on impossible patterns.

Best Practices for Cron Schedules

Use UTC on Servers, Convert at Display Time

Set your servers to UTC (`/etc/timezone` or `TZ=UTC`) and write all cron expressions in UTC. Convert to local time only at display time in your dashboards and reports. This eliminates an entire category of timezone bugs that hit hardest during daylight-saving transitions, when local-time schedules silently double-fire or skip a run. Use the UTC toggle in this tool to design your schedule in UTC from the start.

Avoid the POSIX Day-of-Month/Day-of-Week OR Trap

Never restrict both day-of-month AND day-of-week unless you want OR semantics. If you want "every Monday in January", write `0 0 * 1 1` (day-of-month is `*`); if you want "the 1st of every month", write `0 0 1 * *` (day-of-week is `*`). The POSIX OR rule means `0 0 1 * 1` runs on the 1st AND every Monday — almost certainly not what you intended. The next-run preview will catch this if you check before deploying.

Lock the Schedule's Timezone Explicitly

Modern schedulers support pinning the timezone in the schedule definition: `CRON_TZ=America/New_York` at the top of a crontab (vixie cron 3.0+), `spec.timeZone: "America/New_York"` for Kubernetes CronJobs 1.27+, schedule expression with `ScheduleExpressionTimezone` for AWS EventBridge Scheduler. Lock the timezone explicitly rather than relying on the server's default — server timezones can change without warning during infrastructure migrations.

Spread Load Across Minutes, Not at :00

Avoid `0 * * * *` (every hour at minute 0) for non-critical jobs — at scale, scheduling many things at exactly :00 creates load spikes. Pick a random minute offset (`23 * * * *`, `41 * * * *`) for each job to spread load. The same applies for daily jobs: `30 3 * * *` is friendlier to your database than `0 3 * * *` when many jobs converge at 3:00.

Make Jobs Idempotent

Cron has no built-in retry, no overlap prevention, no missed-run recovery. Your job should be safe to run multiple times (idempotent) and self-checking. Instead of "send report at 9 AM", design it as "send today's report if not already sent" — this self-heals after downtime, accidental double schedules, and concurrent runs. Idempotency is a property of the job, not the scheduler, and it's the single most important reliability practice.

Add a Heartbeat for Critical Schedules

Cron's silent failure mode is its biggest weakness — if the schedule doesn't fire, nothing tells you. For critical jobs, have the job ping a heartbeat service (Healthchecks.io, Cronitor, Dead Man's Snitch) at the end of each run; the service alerts you if the expected ping doesn't arrive. This catches both the job failing and the schedule itself misfiring. Free tier covers most personal and small-team needs.

Verify with the Next-Run Preview Before Shipping

Before deploying a new cron schedule, look at the five upcoming run datetimes in this tool's preview. Toggle between Local and UTC. Confirm the schedule lands when you intend — not five minutes early, not on the wrong day, not skipping the weekend you cared about. The preview is the cheapest possible production test.

Frequently Asked Questions