Cron Expression Explainer

Translate cron expressions into plain English, see the next 5 scheduled run times, and explore common examples. All client-side.

Cron Expression
Common Cron Examples
ExpressionDescription
Quick Reference
FieldAllowed ValuesSpecial Chars
Minute0–59* , - /
Hour0–23* , - /
Day of Month1–31* , - / ?
Month1–12* , - /
Day of Week0–6 (Sun=0)* , - /

Frequently Asked Questions

A cron expression is a string of five fields separated by spaces that specifies when a scheduled task should run: minute hour day-of-month month day-of-week. The asterisk * means "every". For example, 0 0 * * * means "at midnight every day" and */15 * * * * means "every 15 minutes".
The slash defines a step value. */5 in the minute field means "every 5 minutes". 0/15 means "starting at 0, every 15 units". Steps are especially useful for scheduling tasks at regular intervals without listing every value.
The five cron fields and their valid ranges: Minute (0–59), Hour (0–23), Day of month (1–31), Month (1–12 or JAN–DEC), Day of week (0–7 where both 0 and 7 represent Sunday). Special characters: * = every value; , = list; - = range; / = step.
Many cron implementations support shorthand strings: @reboot — runs once at startup; @yearly — runs January 1st at midnight (0 0 1 1 *); @monthly — runs the 1st of each month at midnight; @weekly — runs Sunday at midnight; @daily — runs every day at midnight (0 0 * * *); @hourly — runs at the start of each hour.
Standard cron uses the system timezone of the server — whatever is configured in /etc/timezone. If your server is in UTC and you want a job at 9am New York time, you must calculate the UTC offset. Best practice: keep servers in UTC and document any timezone conversions explicitly in comments alongside the cron expression.
crontab -e manages a per-user crontab. /etc/cron.d/ holds system-wide crontab files — each file can specify a user column to run jobs as a specific user. /etc/cron.daily/ (and weekly, monthly) contain shell scripts that run-parts executes at predefined intervals. For application-level scheduled tasks, /etc/cron.d/ with an explicit username is the cleanest approach.
Common debugging steps: 1. Check the cron log — grep CRON /var/log/syslog. 2. Redirect output — add 2>&1 >> /tmp/cron.log to capture stdout and stderr. 3. Check environment — cron runs with a minimal PATH; use full paths for commands. 4. Check permissions — the cron script must be executable. 5. Verify the expression — use this tool to confirm the schedule.
Shared hosting providers typically impose restrictions: minimum interval — most restrict jobs to run no more than once every 5–15 minutes; execution time limits — jobs are often killed after 30–300 seconds; no root access — you can only edit your own crontab. Workarounds: use a URL-based cron trigger (schedule a wget/curl to a public URL) or use a VPS.
Several modern tools address cron's limitations: systemd timers — support dependency management and logging via journald; AWS EventBridge Scheduler — fully managed, serverless, sub-minute precision; GitHub Actions scheduled workflows — free for public repos, uses cron syntax; Kubernetes CronJobs — run containerized tasks with retry policies; Laravel Scheduler — requires only one cron entry with all logic in code.
Use the step syntax: */5 * * * * /path/to/command. The */5 in the minute field means "every value divisible by 5" — at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55. Other intervals: every 15 minutes: */15 * * * *; every 2 hours: 0 */2 * * *; every weekday at 9am: 0 9 * * 1-5.

About This Cron Explainer

This free cron explainer parses any cron expression and describes it in plain English, showing the next 5 scheduled run times. Enter a 5-field cron expression to see exactly when it will execute.

When to use this tool

  • Verifying a cron schedule before deploying to production
  • Debugging why a scheduled job ran at unexpected times
  • Learning cron syntax interactively with real examples
  • Generating expressions for common intervals (hourly, daily, weekly)

Related Developer Tools

Timestamp Converter Regex Tester JSON Formatter UUID Generator

Related Articles

In-depth guides and technical articles.

View all →
Developer Jul 3, 2026
Kubernetes CronJob vs Traditional Cron — ConcurrencyPolicy, TimeZone Support, and Why Serverless Changes Everything
Kubernetes CronJob adds concurrencyPolicy (Forbid/Allow/Replace), startingDeadlineSeconds for missed run recovery, and — since Kubernetes 1.25 — a timeZone field that classic crontab never had. Here's how cloud-native scheduling differs from traditional cron, why serverless functions with 15-minute execution limits need Step Functions for long-running jobs, how Airflow's catchup=True causes burst runs after maintenance windows, and why GitHub Actions cron is always UTC.
Developer Jun 19, 2026
Cron Doesn't Know What Timezone You Mean — The Server Timezone, Database Desync, and Kubernetes TimeZone Fix
A cron job at "0 9 * * *" doesn't run at 9 AM — it runs at 9 AM in whatever timezone the server is configured for, which may not match the timezone you're thinking in, your users' timezone, or your database's timestamp timezone. Here's the server timezone hidden dependency, why "send at 8 AM" is ambiguous without specifying a timezone, the database timestamp desync pattern, and the Kubernetes timeZone field that finally makes cron timezone-aware.
Developer Jun 14, 2026
Cron and Daylight Saving Time: Why Your 2:30 AM Job Didn't Run — or Ran Twice
A cron job scheduled for 2:30 AM doesn't run on "spring forward" night, because 2:30 AM doesn't exist that night — and the same job might run twice on "fall back" night, because 2:30 AM happens twice. Here's why this is exactly the time window many maintenance jobs use, why UTC eliminates the problem entirely for most automated jobs, and why "9 AM local time" scheduling that survives DST requires timezone-aware libraries, not static cron expressions.
Developer Jun 14, 2026
How the Cron Daemon Works: OS Scheduling, Process Priority, and When to Use systemd Timers Instead
Cron wakes up once per minute, runs with a minimal PATH, and executes via /bin/sh — which is why working shell commands often fail in crontabs. Here's how crond works as a daemon, why environment variables must be set explicitly, process priority with nice values, and why systemd timers handle missed jobs better.
Developer Jun 10, 2026
Production Scheduled Jobs: Idempotency, Monitoring, and Modern Alternatives to Cron
Cron jobs fail silently and traditional cron has no alerting, no history, and no overlap prevention. Here's idempotency design for scheduled jobs, modern alternatives (Celery Beat, AWS EventBridge, Kubernetes CronJobs), and the dead man's switch monitoring pattern.