Cron Expression Generator

A cron expression is a schedule written as five space-separated fields — minute, hour, day of month, month, and day of week — that a scheduler evaluates once per minute to decide when a job runs. This generator builds and validates the expression visually, translates it to plain English, previews the next five run times in any timezone, and produces platform-ready snippets.

Cron expression

Natural language (optional)

Visual builder

Minute MIN

Hour HR

Day of month DOM

Month MON

Day of week DOW

Presets

Human description

At 09:00 AM, only on Monday

Next 5 runs

Timezone

2026-08-03 09:00:00 UTC
2026-08-10 09:00:00 UTC
2026-08-17 09:00:00 UTC
2026-08-24 09:00:00 UTC
2026-08-31 09:00:00 UTC

Code snippets

GitHub Actions

name: Scheduled workflow
on:
  schedule:
    - cron: '0 9 * * 1'
  workflow_dispatch:

jobs:
  scheduled:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run job
        run: echo "Running scheduled job"

• Workflows scheduled at the top of the hour may be delayed during high-load periods. Consider offsetting the minute field (e.g. "5 9 * * 1") for more reliable timing.
• Scheduled workflows run only on the default branch.
• Public repos: workflow auto-disabled after 60 days of no activity.
• workflow_dispatch added for manual testing — a common community pattern that lets you trigger the workflow manually without waiting for the next scheduled run.

Kubernetes CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cron-job
spec:
  schedule: "0 9 * * 1"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job
              image: my-image:latest
              command: ["/bin/sh", "-c", "echo Running"]
          restartPolicy: OnFailure

• CronJob name must be a valid DNS subdomain, max 52 characters.
• Without timeZone field, schedules use the kube-controller-manager local timezone (not necessarily UTC). Set timeZone explicitly for predictable behavior.
• Do NOT use CRON_TZ or TZ inside the schedule string. Kubernetes 1.29+ rejects this at creation with a validation error; earlier versions issue a warning. Existing CronJobs using TZ/CRON_TZ will continue to warn on update. Use the timeZone field instead.
• Production tip: consider concurrencyPolicy (Allow/Forbid/Replace) and startingDeadlineSeconds for robust scheduling.
• Kubernetes supports shorthand macros: @yearly, @monthly, @weekly, @daily, @hourly.

Vercel Cron

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [
    {
      "path": "/api/cron",
      "schedule": "0 9 * * 1"
    }
  ]
}

• Save this as vercel.json in the project root.
• Hobby plan: invocations occur within the specified hour (e.g. "0 8 * * *" runs between 08:00:00 and 08:59:59).
• Pro plan and above: invocations occur within the specified minute (e.g. "5 8 * * *" runs between 08:05:00 and 08:05:59).
• Vercel does not retry failed invocations. Design your handler to be idempotent.
• Vercel may deliver the same cron event more than once. Use unique IDs and check state before making changes.
• Production tip: secure cron endpoints with a CRON_SECRET environment variable. Vercel sends it as a Bearer token in the Authorization header.
• Cron-triggered endpoints should not return 3xx redirects — Vercel does not follow them.

crontab

# Edit your crontab: crontab -e
0 9 * * 1 /path/to/command

# With logging:
0 9 * * 1 /path/to/command >> /var/log/cron.log 2>&1

• crontab uses the system timezone by default. Set CRON_TZ directive or TZ environment variable to override.
• Most modern implementations (vixie-cron, cronie) support shorthand macros: @yearly, @monthly, @weekly, @daily, @hourly, @reboot. These are not defined by POSIX — check your platform.
• Use absolute paths for commands. cron runs with a minimal environment.
• Always check OS timezone with `date` to verify execution time.

Field reference

Field	Allowed values	Special chars
Minute	0–59	* , - /
Hour	0–23	* , - /
Day of month	1–31	* , - / L W
Month	1–12	* , - /
Day of week	0–6 (Sun=0)	* , - / L #

* Every value

, List (0,15,30)

- Range (1-5)

/ Step (*/5)

How to use

Build your expression

Use the visual builder, click a preset, or type an expression directly. You can also try natural language like "every monday at 9am."

Verify the schedule

Read the human description and check the next 5 run times in your timezone. Change the timezone selector to see run times in different regions.

Copy a code snippet

Switch between GitHub Actions, Kubernetes, Vercel, and crontab tabs to get the platform-specific snippet. Click to copy.

Understanding cron expressions

A cron expression is a five-field string that tells a scheduler when to run a recurring job. Reading left to right, the fields are minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). Each field holds a literal value, an asterisk meaning every value, or a combination of the special characters below. The scheduler checks the expression against the clock once per minute and fires the job when every field matches, with one classic exception: when both day-of-month and day-of-week are restricted, standard cron fires when either one matches. So * * * * * runs every minute, 0 9 * * 1 runs at 09:00 every Monday, and 30 2 1 * * runs at 02:30 on the first day of each month. These semantics come from the crontab(5) manual and are shared by virtually every scheduler that consumes cron syntax.

Three special characters cover nearly every real-world schedule. The slash creates step values: */15 in the minute field means every 15 minutes, and 0 */6 * * * runs every 6 hours on the hour. The comma builds lists: 0 9,17 * * * runs at 09:00 and 17:00. The hyphen defines ranges: 0 9 * * 1-5 runs at 09:00 Monday through Friday. These forms combine freely — */10 9-17 * * 1-5 runs every 10 minutes from 09:00 to 17:50 on weekdays, and a range with a step such as 0-30/10 expands to 0, 10, 20, and 30. Steps count from the start of the range rather than from the previous run, so */7 in the minute field fires at minutes 0, 7, 14, 21, 28, 35, 42, 49, and 56, then restarts at the top of the next hour.

Every major platform accepts this same five-field format; what differs is timezone defaults, minimum intervals, and delivery guarantees. GitHub Actions and Vercel evaluate schedules in UTC, while Kubernetes CronJobs and classic crontab follow their host's local timezone unless one is set explicitly. The snippet section above generates ready-to-paste configuration for each environment, and the cron expression cheat sheet documents every platform difference in detail.

Common schedules

Each schedule links to a dedicated reference page with the expression explained field by field, upcoming run times, and platform-ready snippets.

Frequently asked questions

What is a cron job?

A cron job is a scheduled task that runs automatically at specified intervals on a Unix-like system. The name comes from "cron," the time-based job scheduler in Unix. Cron jobs are commonly used for tasks like database backups, report generation, cache clearing, and sending scheduled emails. Each job is defined by a cron expression that specifies when it should run.

How do I read a cron expression?

A cron expression has five fields separated by spaces: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). The asterisk (*) means "every" for that field. For example, "0 9 * * 1" means "at 09:00 on every Monday." The human-readable description on this page translates any expression automatically.

What is the difference between * and ? in cron expressions?

The asterisk (*) matches every value for a field. The question mark (?) is used in some cron systems (like Quartz) to indicate "no specific value" for the day-of-month or day-of-week field — because both cannot be set at the same time. Standard Unix cron does not use ?. If you see a ? in a cron expression, you are likely working with a Java or enterprise scheduler.

How do I run a cron job every 5 minutes?

Use the */5 notation in the minute field: "*/5 * * * *". The slash notation means "every N units." So */5 in the minute field means every 5 minutes, */2 in the hour field means every 2 hours, and so on. You can also list specific minutes: "0,5,10,15,20,25,30,35,40,45,50,55 * * * *" is equivalent but more verbose.

Why does my cron job not run?

Common causes: (1) The cron daemon is not running — check with "systemctl status cron" or "crontab -l". (2) The expression is invalid — paste it into this tool to validate it. (3) The command path is wrong — cron runs with a minimal environment, so use absolute paths. (4) Timezone mismatch — cron uses the system timezone, not your local timezone. (5) Permissions — the user running cron may not have execute permission on the script.

What is the difference between cron syntax in Vercel, GitHub Actions, Kubernetes, and crontab?

All four platforms accept the standard 5-field cron syntax; the differences are timezone handling and frequency limits. GitHub Actions runs in UTC, ignores schedules shorter than 5 minutes, and only schedules workflows on the default branch. Kubernetes CronJobs default to the controller's local timezone; set the timeZone field (stable in 1.27+) instead of CRON_TZ. Vercel Cron is UTC-only, limits Hobby plans to one run per day, and does not retry failures. crontab uses the system timezone, overridable with CRON_TZ or TZ. See the cron cheat sheet for full platform behavior.

Learn more

Cron Expression Cheat Sheet May 13, 2026

Other tools you might find useful

Unix Timestamp Convert between Unix timestamps and human-readable dates Timezone Converter Convert times across any IANA timezone pair ISO 8601 Parse and format ISO 8601 datetime strings