Cron Expressie Online Gids: Syntax, Voorbeelden, Omgevingen en Best Practices

Cron expressions are the backbone of task scheduling across Unix/Linux systems, cloud platforms, and CI/CD pipelines. Whether you need to run a database backup every night at 3 AM, send weekly reports every Monday, or trigger a build pipeline every 15 minutes, cron expressions give you precise, declarative control over when your jobs execute. This comprehensive guide covers everything from basic 5-field syntax to advanced special characters, platform-specific differences, timezone handling, debugging techniques, and security considerations.

What Is a Cron Expression?

A cron expression is a compact, whitespace-separated string that tells a scheduler exactly when to run a task. The term "cron" comes from the Greek word "chronos" meaning time. The cron daemon (crond) has been a core part of Unix-like operating systems since the 1970s, and its expression syntax has become the universal standard for time-based scheduling.

The most widely used format is the 5-field expression, where each field represents a time unit. Some implementations extend this to 6 or 7 fields.

5-Field Format (Standard Cron)

The standard cron expression used in Linux crontab, Kubernetes CronJob, GitHub Actions, and Vercel Cron:

┌───────────── Minute (0–59)
│ ┌─────────── Hour (0–23)
│ │ ┌───────── Day of Month (1–31)
│ │ │ ┌─────── Month (1–12)
│ │ │ │ ┌───── Day of Week (0–7)
│ │ │ │ │
* * * * *

6-Field Format (Quartz / Spring)

Used by Java-based schedulers like Quartz, Spring @Scheduled, and AWS CloudWatch Events:

┌─────────────── seconds (0–59)
│ ┌───────────── Minute (0–59)
│ │ ┌─────────── Hour (0–23)
│ │ │ ┌───────── Day of Month (1–31)
│ │ │ │ ┌─────── Month (1–12)
│ │ │ │ │ ┌───── Day of Week (0–7)
│ │ │ │ │ │
* * * * * *

Field-by-Field Breakdown

0      → at the top of the hour
*/5    → every 5 minutes (0, 5, 10, 15, ...)
15,45  → at minute 15 and 45
10-20  → every minute from 10 through 20

0      → midnight
9      → 9 AM
9-17   → every hour from 9 AM to 5 PM
*/4    → every 4 hours (0, 4, 8, 12, 16, 20)

1      → first day of month
15     → 15th of the month
1,15   → 1st and 15th
L      → last day (Quartz only)

1       → January
*/3     → every 3 months (Jan, Apr, Jul, Oct)
6-8     → June through August
1,4,7,10 → quarterly (Jan, Apr, Jul, Oct)

0 or 7  → Sunday
1       → Monday
1-5     → Monday through Friday (weekdays)
0,6     → Saturday and Sunday (weekend)
5#3     → 3rd Friday (Quartz only)

Special Characters Explained

Asterisk (*)

Matches every possible value for that field. Using * in the minute field means "every minute" (0 through 59).

* * * * *     # every minute of every hour of every day

Slash (/)

Defines step values (increments). */15 in the minute field means "every 15 minutes" (0, 15, 30, 45). You can also combine with a start value: 5/15 means "every 15 minutes starting at minute 5" (5, 20, 35, 50).

*/10 * * * *  # every 10 minutes
5/15 * * * *  # minutes 5, 20, 35, 50
0 */6 * * *   # every 6 hours at minute 0

Dash (-)

Defines an inclusive range. 9-17 in the hour field means "every hour from 9 AM to 5 PM". 1-5 in the day-of-week field means "Monday through Friday".

0 9-17 * * *  # hourly from 9 AM to 5 PM
0 0 * * 1-5   # midnight, Monday through Friday

Comma (,)

Specifies a list of discrete values. 1,15 in the day-of-month field means "the 1st and 15th of the month". 0,30 in the minute field means "at minute 0 and minute 30".

0 0 1,15 * *  # 1st and 15th at midnight
0 8,12,18 * * * # at 8 AM, noon, and 6 PM

L (Last)

Available in Quartz and some extended implementations. In the day-of-month field, L means "the last day of the month". In the day-of-week field, 5L means "the last Friday of the month".

# Quartz / Spring only:
0 0 L * ?     # last day of every month at midnight
0 0 ? * 5L    # last Friday of every month at midnight

W (Weekday)

Available in Quartz and extended implementations. 15W in the day-of-month field means "the nearest weekday (Mon-Fri) to the 15th". If the 15th is a Saturday, the job runs on Friday the 14th.

# Quartz only:
0 0 15W * ?   # nearest weekday to the 15th at midnight
0 0 1W * ?    # nearest weekday to the 1st at midnight

Hash (#)

Available in Quartz. Specifies "the Nth weekday of the month". 5#3 in the day-of-week field means "the third Friday of every month". 1#1 means "the first Monday of each month".

# Quartz only:
0 10 ? * 5#3  # 3rd Friday at 10 AM
0 9 ? * 1#1   # 1st Monday at 9 AM
0 9 ? * 1#2   # 2nd Monday at 9 AM

Question Mark (?)

Used in Quartz and AWS to indicate "no specific value" for day-of-month or day-of-week. Required when one of these two fields has a specific value and the other must be left open.

# AWS / Quartz:
0 10 ? * 2    # every Monday at 10 AM (? for day-of-month)
0 0 15 * ?    # 15th of month at midnight (? for day-of-week)

Common Cron Patterns with Examples

Cron in Different Environments

Linux Crontab

The classic cron implementation. Edit with "crontab -e", list with "crontab -l". Uses 5-field syntax. Runs in the system timezone by default. Supports MAILTO for emailing output.

# Edit current user's crontab
crontab -e

# List current crontab entries
crontab -l

# Example: backup database daily at 3 AM
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# Set timezone (at top of crontab)
TZ=America/New_York
0 9 * * * /path/to/script.sh

# Send output via email
MAILTO=admin@example.com
0 6 * * 1 /path/to/weekly-report.sh

AWS EventBridge (CloudWatch Events)

AWS uses a 6-field format: minute, hour, day-of-month, month, day-of-week, year. Requires ? for either day-of-month or day-of-week. Supports UTC only by default (EventBridge Scheduler supports timezones). Rate expressions are an alternative: rate(5 minutes).

# AWS EventBridge 6-field format:
# minute hour day-of-month month day-of-week year

# Every 5 minutes
cron(*/5 * * * ? *)

# Daily at 10 AM UTC
cron(0 10 * * ? *)

# First Monday of every month at 8 AM
cron(0 8 ? * 2#1 *)

# Rate expression alternative
rate(5 minutes)
rate(1 hour)
rate(7 days)

GitHub Actions

Uses standard 5-field POSIX cron syntax in the schedule trigger. Runs in UTC only. Minimum interval is every 5 minutes. Jobs may be delayed during high load. Defined in .github/workflows/*.yml under on.schedule.

# .github/workflows/scheduled.yml
name: Scheduled Job
on:
  schedule:
    # Runs at 06:00 UTC every day
    - cron: '0 6 * * *'
    # Runs every 15 minutes
    - cron: '*/15 * * * *'
    # Runs every Monday at 9 AM UTC
    - cron: '0 9 * * 1'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Triggered by cron schedule"

Kubernetes CronJob

Uses standard 5-field cron syntax in spec.schedule. Runs in the timezone of the kube-controller-manager (usually UTC). Starting from Kubernetes 1.27, you can set spec.timeZone (e.g., "America/New_York"). Supports concurrencyPolicy: Allow, Forbid, or Replace.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: database-backup
spec:
  schedule: "0 3 * * *"          # daily at 3 AM
  timeZone: "America/New_York"   # K8s 1.27+
  concurrencyPolicy: Forbid      # prevent overlapping
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: postgres:16
            command: ["/bin/sh", "-c", "pg_dump ..."]
          restartPolicy: OnFailure

Vercel Cron

Defined in vercel.json under the crons array. Uses standard 5-field syntax. Runs in UTC. Triggers a serverless function at the specified path. Free tier allows 2 cron jobs per project; Pro tier allows more.

// vercel.json
{
  "crons": [
    {
      "path": "/api/daily-cleanup",
      "schedule": "0 0 * * *"
    },
    {
      "path": "/api/hourly-sync",
      "schedule": "0 * * * *"
    }
  ]
}

Cron Expression Parsing Libraries

Node.js: cron-parser

The most popular cron parsing library for Node.js. Parses cron expressions and calculates the next N occurrence dates. Supports 5-field and 6-field (with seconds) formats.

import { parseExpression } from 'cron-parser';

const interval = parseExpression('*/15 * * * *');
console.log('Next:', interval.next().toString());
console.log('Next:', interval.next().toString());
console.log('Next:', interval.next().toString());

// With options
const options = {
  currentDate: new Date('2026-01-01T00:00:00'),
  tz: 'America/New_York'
};
const expr = parseExpression('0 9 * * 1-5', options);
for (let i = 0; i < 5; i++) {
  console.log(expr.next().toString());
}

Python: croniter

The standard Python library for iterating over cron schedule dates. Supports standard 5-field and extended 6-field expressions. Works well with datetime objects.

from croniter import croniter
from datetime import datetime

base = datetime(2026, 1, 1)
cron = croniter('0 9 * * 1-5', base)

# Get next 5 occurrences
for _ in range(5):
    print(cron.get_next(datetime))

# Check if a specific time matches
print(croniter.match('0 9 * * 1', datetime(2026, 3, 2, 9, 0)))
# True (March 2, 2026 is a Monday)

Other Languages

Go: robfig/cron (the de facto standard). Java: Quartz Scheduler (includes its own cron parser). Rust: cron crate. PHP: dragonmantank/cron-expression.

// Go: robfig/cron v3
import "github.com/robfig/cron/v3"

c := cron.New()
c.AddFunc("0 9 * * 1-5", func() {
    fmt.Println("Weekday morning job")
})
c.Start()

// Rust: cron crate
use cron::Schedule;
let schedule = Schedule::from_str("0 9 * * 1-5").unwrap();
for dt in schedule.upcoming(Utc).take(5) {
    println!("{}", dt);
}

Timezone Handling in Cron Jobs

Timezone mismanagement is the number one source of cron job bugs. Different systems handle timezones differently:

• Linux crontab: Runs in the system timezone. Set the TZ variable at the top of crontab to override.
• GitHub Actions: Always UTC. No timezone configuration available.
• AWS EventBridge: UTC by default. EventBridge Scheduler supports IANA timezones.
• Kubernetes: Controller timezone (usually UTC). Use spec.timeZone (Kubernetes 1.27+) for per-job timezone.
• Vercel Cron: Always UTC.

Daylight Saving Time (DST) Considerations

When your cron job depends on local time and your timezone observes DST, jobs can be skipped or run twice during clock changes. Spring forward: a 2:30 AM job may be skipped. Fall back: a 1:30 AM job may run twice. Best practice is to run critical jobs in UTC and convert timestamps in your application logic.

# Best practice: run in UTC and convert in your app
TZ=UTC
0 8 * * *  /path/to/job.sh   # always 08:00 UTC

# Inside job.sh, convert to local time if needed:
LOCAL_TIME=$(TZ="America/New_York" date)

Debugging Cron Jobs: Logging, Monitoring & Alerting

Logging Output

Always redirect stdout and stderr to a log file. In crontab:

# Redirect both stdout and stderr
*/5 * * * * /path/to/job.sh >> /var/log/myjob.log 2>&1

# With timestamp
*/5 * * * * echo "$(date): starting job" >> /var/log/myjob.log && /path/to/job.sh >> /var/log/myjob.log 2>&1

# Send output via email
MAILTO=dev@example.com
0 6 * * * /path/to/morning-report.sh

Monitoring

Use a dead-man-switch service (Cronitor, Healthchecks.io, Better Uptime) where your cron job pings a URL on success. If the ping does not arrive within the expected window, you get alerted. This catches silent failures where the job runs but produces no output.

# Dead-man switch with Healthchecks.io
0 3 * * * /path/to/backup.sh && curl -fsS --retry 3 https://hc-ping.com/YOUR-UUID

# Dead-man switch with Cronitor
0 3 * * * cronitor exec abc123 /path/to/backup.sh

# Custom alerting with webhook
0 3 * * * /path/to/backup.sh || curl -X POST https://hooks.slack.com/... -d '{"text":"Backup failed!"}'

Alerting

Set MAILTO in crontab to receive email output. For cloud-based cron, integrate with PagerDuty, Opsgenie, or Slack webhooks. Monitor exit codes: a non-zero exit should trigger an alert.

Dry Run Testing

Before deploying, verify your cron expression by calculating the next several execution times. Use our online cron parser tool or the cron-parser library to generate upcoming dates programmatically.

# Verify with cron-parser (Node.js)
npx cron-parser "0 9 * * 1-5"

# Verify in Python
python3 -c "
from croniter import croniter
from datetime import datetime
c = croniter('0 9 * * 1-5', datetime.now())
for _ in range(10):
    print(c.get_next(datetime))
"

Cron vs Alternatives

systemd Timers

Modern Linux alternative to cron. Advantages: better logging via journalctl, dependency management, and resource control with cgroups. Create a .timer unit file paired with a .service file. Supports monotonic timers (run 5 minutes after boot) and calendar-based timers.

# /etc/systemd/system/backup.timer
[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/backup.service
[Unit]
Description=Database backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
User=backup

# Enable and start
systemctl enable --now backup.timer
systemctl list-timers

at Command

One-shot scheduler for running a command once at a specific time. Unlike cron, it does not repeat. Useful for scheduled maintenance or deferred tasks. Syntax: echo "command" | at 3:00 PM tomorrow.

# Schedule a one-time job
echo "/usr/local/bin/maintenance.sh" | at 3:00 AM tomorrow
echo "reboot" | at 2:00 AM Jan 15

# List pending jobs
atq

# Remove a scheduled job
atrm 42

Windows Task Scheduler

The Windows equivalent of cron. GUI-based with XML-backed definitions. Supports triggers (time, event, logon) and conditions (idle, network). Can be managed via PowerShell with the ScheduledTasks module.

# PowerShell: create a scheduled task
$action = New-ScheduledTaskAction -Execute "C:\scripts\backup.ps1"
$trigger = New-ScheduledTaskTrigger -Daily -At 3am
Register-ScheduledTask -TaskName "DailyBackup" -Action $action -Trigger $trigger

# List scheduled tasks
Get-ScheduledTask | Where-Object {$_.State -eq 'Ready'}

Quick Comparison

Common Mistakes and Pitfalls

# Use flock to prevent overlapping
*/5 * * * * flock -n /tmp/myjob.lock /path/to/long-running-job.sh

# Kubernetes concurrencyPolicy
spec:
  concurrencyPolicy: Forbid  # skip if previous still running

# BAD: relative path, no output capture
*/5 * * * * ./cleanup.sh

# GOOD: absolute path, full environment, output redirect
*/5 * * * * /usr/bin/env bash /home/deploy/scripts/cleanup.sh >> /var/log/cleanup.log 2>&1

# This runs on the 15th OR on Mondays (OR logic, not AND)
0 0 15 * 1

# If you want the 15th AND it must be a Monday,
# use a wrapper script with date checks instead.

Security Considerations for Cron Jobs

# Restrict cron access
echo "deploy" >> /etc/cron.allow
echo "www-data" >> /etc/cron.deny

# Run as non-root user
su - deploy -c "crontab -e"

# GOOD: absolute path
0 3 * * * /home/deploy/scripts/backup.sh

# Secure script permissions
chmod 750 /home/deploy/scripts/backup.sh
chown deploy:deploy /home/deploy/scripts/backup.sh

# Load credentials from a secured file
0 3 * * * . /home/deploy/.env && /home/deploy/scripts/backup.sh

# .env file permissions
chmod 600 /home/deploy/.env
chown deploy:deploy /home/deploy/.env

See also: timestamp converter

Frequently Asked Questions

Conclusion

Cron expressions remain the universal language for time-based task scheduling. From a simple Linux crontab entry to sophisticated Kubernetes CronJobs with timezone support and concurrency policies, the core syntax has stood the test of time since the 1970s.

The keys to reliable cron job management are: understand your platform syntax and timezone, prevent overlapping runs, log all output, monitor execution with dead-man switches, and follow security best practices. Use our online cron expression parser to validate and test your expressions before deploying them to production.