Cron Expression Generator

What Is a Cron Expression? The Complete Guide

A cron expression is a compact string that defines a recurring schedule for automated tasks. Originally designed for the Unix cron daemon in the 1970s, cron expressions have become the universal standard for scheduling across operating systems, cloud platforms, CI/CD pipelines, and application frameworks.

Whether you're scheduling database backups, running periodic health checks, sending weekly reports, or triggering data pipelines, understanding cron syntax is an essential skill for developers, DevOps engineers, and system administrators. This guide covers everything you need to know about cron expressions — from the basics of the five-field format to advanced techniques using special characters.

The 5-Field Cron Format Explained

A standard cron expression consists of five fields separated by spaces. Each field represents a unit of time and together they define precisely when a task should execute:

The general format is: minute hour day-of-month month day-of-week. When all five fields match the current date and time, the scheduled task (or “cron job”) executes. Each field can contain a single value, a list of values, a range, a step value, or a wildcard.

Special Characters in Cron Expressions

Cron expressions support several special characters that give you fine-grained control over scheduling. Understanding these characters is key to writing effective cron schedules:

Asterisk (*) — Wildcard

The asterisk means “every possible value” for that field. For example, * in the hour field means “every hour.” In the expression 0 * * * *, the job runs at minute 0 of every hour, every day, every month, every day of the week — effectively once per hour.

Comma (,) — List

The comma separates multiple specific values. 1,15 in the day-of-month field means “on the 1st and 15th.” You can combine as many values as needed: 0 9 * * 1,3,5 runs at 9 AM on Monday, Wednesday, and Friday. Lists work in any field and are useful when your schedule doesn't follow a regular pattern.

Hyphen (-) — Range

The hyphen defines an inclusive range of values. 1-5 in the day-of-week field means “Monday through Friday.” The expression 0 9-17 * * * runs at the top of every hour from 9 AM to 5 PM. Ranges are especially useful for business-hours scheduling and date-bounded tasks.

Forward Slash (/) — Step

The slash defines step values — intervals within a range. */15 in the minute field means “every 15 minutes” (at 0, 15, 30, and 45). You can combine steps with ranges: 1-30/5 means “every 5 minutes within the first 30 minutes” (at 1, 6, 11, 16, 21, 26). Steps are the most common way to schedule recurring intervals.

Extended Characters: L, W, and # (Quartz / Spring)

Some cron implementations (notably Quartz Scheduler for Java, Spring Framework, and AWS EventBridge) support extended characters. These are not available in standard Unix crontab but are widely used in enterprise environments:

• L (Last) — In the day-of-month field, L means “last day of the month” (28th, 29th, 30th, or 31st depending on the month). In the day-of-week field, 5L means “last Friday of the month.”
• W (Weekday) — Specifies the nearest weekday to a given day of the month. 15W means “the nearest weekday to the 15th.” If the 15th is a Saturday, it fires on Friday the 14th. If it's a Sunday, it fires on Monday the 16th.
• # (Nth occurrence) — Specifies the Nth occurrence of a weekday within a month. 6#3 in the day-of-week field means “the third Friday of the month” (6 = Friday in some implementations, where 1 = Sunday).

Note: Our cron expression generator above uses the standard 5-field Unix format, which is the most widely compatible format across platforms.

Common Cron Expression Examples

Here are the most frequently used cron expressions, organized by frequency. Use our cron expression generator above to customize any of these for your specific needs:

How to Use Cron Expressions: Platform-by-Platform Guide

Linux / Unix Crontab

The original cron implementation. Edit your crontab with crontab -e and add lines in the format:

# Run backup script daily at 2 AM
0 2 * * * /usr/local/bin/backup.sh

# Health check every 5 minutes
*/5 * * * * curl -s https://api.example.com/health > /dev/null

# Weekly database maintenance on Sundays at 3 AM
0 3 * * 0 /usr/local/bin/db-maintenance.sh

Use crontab -l to list your current cron jobs. The cron daemon reads these entries and executes the commands at the specified times. Output is typically emailed to the user or can be redirected to a log file with >> /var/log/cron.log 2>&1.

GitHub Actions

GitHub Actions uses cron expressions in the schedule trigger. Note that GitHub Actions uses UTC time:

on:
  schedule:
    # Run at 9 AM UTC every weekday
    - cron: '0 9 * * 1-5'
    # Run every 6 hours
    - cron: '0 */6 * * *'

Be aware that GitHub Actions scheduled workflows may experience delays during periods of high load. The minimum interval is 5 minutes, and GitHub may disable scheduled workflows on repositories with no activity.

AWS EventBridge (CloudWatch Events)

AWS EventBridge uses a 6-field cron format with an additional “year” field and requires ? in either the day-of-month or day-of-week field:

# AWS cron: min hour day month weekday year
# Daily at midnight UTC
cron(0 0 * * ? *)

# Every Monday at 9 AM UTC
cron(0 9 ? * MON *)

# First day of every month
cron(0 0 1 * ? *)

Kubernetes CronJobs

Kubernetes supports standard 5-field cron expressions in CronJob resources:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: health-check
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: health-check
            image: curlimages/curl
            command: ["curl", "-s", "https://api.example.com/health"]
          restartPolicy: OnFailure

Docker / Docker Compose

Many Docker-based applications accept cron expressions as environment variables. For example, scheduling automated backups:

services:
  backup:
    image: postgres:16
    environment:
      BACKUP_CRON: "0 2 * * *"  # Daily at 2 AM

Node.js (node-cron)

The popular node-cron package brings cron scheduling to Node.js applications:

const cron = require('node-cron');

// Run every 15 minutes
cron.schedule('*/15 * * * *', () => {
  console.log('Running health check...');
  fetch('https://api.example.com/health')
    .then(res => console.log('Status:', res.status));
});

Python (APScheduler / Celery)

Python offers multiple cron scheduling libraries. APScheduler is popular for standalone scripts, while Celery handles distributed task queues:

# APScheduler
from apscheduler.schedulers.blocking import BlockingScheduler
from apscheduler.triggers.cron import CronTrigger

scheduler = BlockingScheduler()

@scheduler.scheduled_job(CronTrigger.from_crontab('0 9 * * 1-5'))
def morning_report():
    print('Generating weekday report...')

scheduler.start()

Cron Expression Best Practices

Writing correct cron expressions is only half the battle. Here are battle-tested practices for production cron jobs:

1. Always Specify the Timezone

Cron expressions don't inherently include timezone information. The execution time depends on the system's configured timezone. In distributed systems, this can cause unexpected behavior:

• Linux crontab: Set CRON_TZ=America/New_York at the top of your crontab
• Kubernetes: Use the timeZone field (GA in v1.27+)
• GitHub Actions: Always uses UTC — adjust your expression accordingly
• AWS EventBridge: Uses UTC by default; newer rules support timezone specification

2. Avoid Midnight Stampedes

Many developers default to 0 0 * * * (midnight) for daily jobs. This causes “thundering herd” problems on shared infrastructure. Stagger your schedules:

# Instead of this (midnight stampede)
0 0 * * * /usr/local/bin/job-a.sh
0 0 * * * /usr/local/bin/job-b.sh
0 0 * * * /usr/local/bin/job-c.sh

# Do this (staggered)
5 0 * * * /usr/local/bin/job-a.sh
20 0 * * * /usr/local/bin/job-b.sh
45 0 * * * /usr/local/bin/job-c.sh

3. Add Dead Man's Switch Monitoring

A “dead man's switch” (or heartbeat monitor) alerts you when a cron job fails to run. This catches silent failures that logs alone won't reveal. After your job completes successfully, have it ping a monitoring URL. If the ping doesn't arrive within the expected window, you get alerted.

# Ping monitoring endpoint after successful backup
0 2 * * * /usr/local/bin/backup.sh && curl -s https://apistatuscheck.com/ping/your-monitor-id

API Status Check supports heartbeat monitoring for exactly this use case — track whether your cron jobs are running on schedule and get instant alerts when they miss a beat.

4. Log Everything

Redirect both stdout and stderr to log files. Include timestamps and exit codes:

*/15 * * * * /usr/local/bin/sync.sh >> /var/log/sync.log 2>&1

5. Use Lock Files to Prevent Overlap

If a cron job takes longer than its interval, you could end up with multiple instances running simultaneously. Use flock on Linux to prevent this:

*/5 * * * * flock -n /tmp/sync.lock /usr/local/bin/sync.sh

6. Test Before Deploying

Use our cron expression validator above to verify your expression before deploying. Check the “next 5 execution times” to make sure the schedule matches your intention. Off-by-one errors in cron fields are surprisingly common and can lead to jobs running at the wrong time (or not at all).

Cron vs. Other Scheduling Approaches

Cron is the de facto standard for time-based scheduling, but it's not the only option. Here's how it compares to alternative approaches:

Cron vs. systemd Timers

Modern Linux systems offer systemd timers as an alternative to cron. Advantages include: built-in logging (via journald), dependency management between services, monotonic timers (e.g., “10 minutes after boot”), and better handling of missed events. However, cron remains more portable and simpler for basic scheduling. Most developers still use cron for its simplicity and universal support.

Cron vs. Cloud Schedulers

Cloud schedulers (AWS EventBridge, Google Cloud Scheduler, Azure Logic Apps) use cron syntax but add features like: retries on failure, dead-letter queues, IAM-based permissions, and event routing. They're ideal for serverless architectures where you can't install traditional cron. The trade-off is vendor lock-in and cost — these services charge per invocation.

Cron vs. Task Queues

Task queues (Celery, Bull/BullMQ, Sidekiq) are better suited for: distributed workloads across multiple workers, tasks that need retry logic, priority-based execution, and sub-minute scheduling. Use cron for simple time-based triggers; use task queues when you need distributed processing or complex workflow orchestration.

Debugging Common Cron Problems

Even experienced developers run into cron issues. Here are the most common problems and their solutions:

Problem: Cron Job Runs But Produces No Output

The most common cause is that cron runs with a minimal environment — it doesn't load your .bashrc or .profile. Commands that work in your terminal may fail in cron because PATH is different. Solution: use absolute paths for all commands and explicitly set environment variables.

Problem: Cron Job Doesn't Run at All

Check these in order: (1) Is the cron daemon running? (systemctl status cron), (2) Is the crontab syntax correct? (use our validator above), (3) Does the user have cron permissions? (check /etc/cron.allow and /etc/cron.deny), (4) Are there any errors in /var/log/syslog or /var/log/cron?

Problem: Wrong Timezone

Your cron job runs at the wrong time? Check the system timezone with timedatectl. In containerized environments, the container timezone may differ from the host. Set TZ=UTC or your desired timezone explicitly.

Problem: Jobs Overlap

A job takes longer than its scheduled interval and multiple instances pile up. Use flock (Linux) or check for a PID file at the start of your script. Monitor execution times and adjust intervals if jobs consistently overrun.

Cron Expression Generator vs. Crontab Guru: Feature Comparison

Our free cron expression generator offers a comparable experience to popular tools like crontab guru, with some additional features:

• Visual builder — Click-based interface with dropdowns and toggles for each field, plus instant presets for the most common schedules
• Expression validator — Paste any cron expression and instantly see what it means in plain English, plus a field-by-field breakdown
• Next 5 execution times — See exactly when your cron job will run next, displayed in your local timezone
• Dark mode support — Comfortable usage for developers who prefer dark themes
• No signup required — Completely free, no account needed, all processing happens in your browser
• Mobile-responsive — Full functionality on phones and tablets

Whether you call it a cron schedule builder, crontab generator, or cron syntax helper — this tool does it all. And when you're ready to monitor the cron jobs you've built, API Status Check has you covered with real-time uptime monitoring and instant alerts.

History of Cron: From AT&T Unix to the Modern Cloud

The cron utility has a fascinating history that spans five decades of computing:

1975 — The original cron was written by Ken Thompson for Version 7 Unix at AT&T Bell Labs. It used a simple format and ran as a system daemon, waking up every minute to check for scheduled tasks.

1987 — Paul Vixie wrote “Vixie cron,” which became the standard cron implementation on most Unix and Linux systems. It introduced per-user crontabs (via crontab -e), environment variable support, and the @reboot shorthand. Vixie cron is still the default on most Linux distributions today.

2000s — As web applications grew, cron found new life in web hosting control panels (cPanel, Plesk) and PHP frameworks. The expression format was adopted by job schedulers in Java (Quartz), Python (Celery), and Ruby (whenever gem).

2010s–Present — Cloud platforms adopted cron expressions as the standard for scheduled events: AWS CloudWatch Events (now EventBridge), Google Cloud Scheduler, Azure Functions timer triggers, and GitHub Actions all use cron syntax. Kubernetes added CronJob resources in v1.8 (2017), bringing cron scheduling to container orchestration.

Today, cron expressions are arguably the most widely understood scheduling format in software engineering. The five-field syntax has remained remarkably stable over nearly 50 years — a testament to its elegant simplicity.

Why Monitor Your Cron Jobs?

Cron jobs are the backbone of automated infrastructure — but they fail silently. Unlike a web server that returns a 500 error, a failed cron job simply doesn't run. No one notices until the consequences surface: stale data, missed backups, unfulfilled orders, expired certificates.

API Status Check solves this with heartbeat monitoring. After building your cron expression with our generator, set up a monitor to track execution:

• Get alerted within minutes when a scheduled job misses its window
• Monitor the APIs and services your cron jobs depend on
• Track uptime history and identify patterns in job failures
• Receive alerts via email, Slack, Discord, or webhook

Start monitoring your cron jobs for free →

Frequently Asked Questions About Cron Expressions

What is a cron expression?

A cron expression is a string of five fields separated by spaces that defines a schedule for automated tasks. The five fields represent minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). For example, 0 9 * * 1-5 means “at 9:00 AM, Monday through Friday.” Cron expressions are used in Unix/Linux cron jobs, CI/CD pipelines, cloud schedulers (AWS EventBridge, Google Cloud Scheduler), and monitoring systems.

What does */5 mean in a cron expression?

The */5 notation means “every 5th unit.” In the minute field, */5 means “every 5 minutes” — firing at 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 minutes past the hour. The forward slash (/) is the step operator, dividing the range into intervals. You can use it in any field: */2 in the hour field means “every 2 hours,” */3 in the month field means “every 3 months.”

How do I write a cron expression for every 5 minutes?

To run a cron job every 5 minutes, use the expression */5 * * * *. The first field (*/5) sets the minute interval to every 5 minutes. The remaining asterisks (*) mean “every hour, every day of the month, every month, every day of the week.” This is one of the most common cron schedules, frequently used for health checks and monitoring.

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

In standard Unix cron (5-field format), only * is used as a wildcard meaning “every value.” The ? character is specific to extended cron formats used in Quartz Scheduler (Java) and AWS CloudWatch/EventBridge, where it means “no specific value” and is required in either the day-of-month or day-of-week field. In standard crontab, you do not need the ? character.

How do I schedule a cron job for weekdays only?

Use 0 9 * * 1-5 to run at 9 AM Monday through Friday. The fifth field (day of week) uses a range: 1 (Monday) through 5 (Friday). Adjust the time by changing the first two fields — for example, 30 8 * * 1-5 runs at 8:30 AM on weekdays.

What does 0 0 * * * mean in cron?

0 0 * * * means “at midnight (00:00) every day.” The first field (0) sets the minute to 0, the second field (0) sets the hour to midnight, and the remaining wildcards mean every day. This is the most common expression for daily jobs like database backups, log rotation, and report generation.

Can I use cron expressions to run a job every 30 seconds?

No, standard cron expressions have a minimum granularity of one minute. The smallest interval is * * * * * (every minute). For sub-minute scheduling, use systemd timers, process managers with sleep loops, task queues like Celery or Bull, or specialized sub-minute schedulers available on some cloud platforms.

How do I monitor cron jobs to make sure they run?

The best approach is heartbeat monitoring: have your cron job ping a monitoring endpoint after each successful execution. API Status Check monitors these heartbeat URLs — if a ping is missed (meaning your cron job failed), you get an instant alert via email, Slack, or webhook. This is far more reliable than manually checking log files.