← Blog  ·  October 2026

Cron Expression Examples: 60+ Real-World Cron Schedules

60+ copy-paste-ready cron expressions for real-world tasks: backups, reports, deployments, cache warmups, cleanups, and more.

Cron expressions are one of those things you reach for repeatedly but never quite commit to memory. This page has two parts: real-world use cases (specific tasks with the cron expression that fits) and a complete reference organized by schedule frequency. If you know what you need to schedule but can’t remember the syntax, start with the use cases.

Real-world use cases

The right schedule depends on what the job does. Here are common real-world tasks with the cron expression that fits each one.

System maintenance

Application jobs

Data pipelines and syncs

CI/CD and deployment jobs

Monitoring and alerting

Every N minutes

The */n syntax means "every n units." */15 * * * * fires at :00, :15, :30, and :45 of each hour. Note that */7 * * * * does not fire "every 7 minutes consistently" — it fires at minutes 0, 7, 14, 21, 28, 35, 42, 49, 56, and then resets at the top of the next hour. If consistent intervals across hours matter, use a different approach.

Every N hours

Daily schedules

The @daily shorthand is equivalent to 0 0 * * * on most systems.

Weekday-only schedules

In standard cron, 1-5 means Monday through Friday. Day-of-week values: 0 or 7 = Sunday, 1 = Monday, …, 6 = Saturday.

Weekly schedules

The @weekly shorthand is equivalent to 0 0 * * 0.

Monthly schedules

Specific times and patterns

Commas in any field mean "or" — 1,3,5 in the day-of-week field means Monday, Wednesday, or Friday.

@-shorthand expressions

Most cron implementations support convenient @-shorthands:

Platform-specific examples

GitHub Actions

GitHub Actions uses standard 5-field cron syntax in UTC. The schedule trigger fires approximately on time but not exactly — GitHub queues jobs during high-load periods.

on:
  schedule:
    - cron: '0 6 * * 1-5'     # Weekdays at 6:00 AM UTC
    - cron: '*/15 * * * *'    # Every 15 minutes (note: not recommended for high-frequency polling)
    - cron: '0 0 * * 0'       # Weekly on Sunday at midnight UTC

Important: GitHub Actions cron jobs that haven't run for 60 days on an inactive repository will be disabled automatically.

AWS EventBridge (CloudWatch Events)

AWS supports two formats: cron (6 fields, with year) and rate expressions.

# AWS cron format: cron(minute hour day-of-month month day-of-week year)
cron(0 9 * * ? *)          # Every day at 9:00 AM UTC (? = no specific day-of-week)
cron(0 */4 * * ? *)        # Every 4 hours
cron(0 0 1 * ? *)          # First day of every month at midnight

# Rate expressions (simpler for intervals)
rate(5 minutes)
rate(1 hour)
rate(1 day)

AWS uses ? (not *) when day-of-month and day-of-week conflict. You must use ? in one of the two fields when the other is specified.

Kubernetes CronJob

Kubernetes uses standard 5-field cron syntax in the server's local timezone (usually UTC).

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 3 * * *"       # Every day at 3:00 AM
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: report
            image: myapp:latest
            command: ["python", "report.py"]

Node.js (node-cron)

The popular node-cron library uses a 5 or 6-field format (optionally with seconds as the first field):

import cron from 'node-cron';

// Standard 5-field
cron.schedule('0 * * * *', () => console.log('Every hour'));
cron.schedule('*/5 * * * *', () => console.log('Every 5 minutes'));

// 6-field (with seconds as first field)
cron.schedule('*/30 * * * * *', () => console.log('Every 30 seconds'));

Common mistakes and gotchas

Minutes vs. hours confusion

0 */4 * * * (every 4 hours) is not the same as */4 0 * * * (every 4 minutes during the midnight hour only). The order matters: minute, hour, day, month, weekday.

Timezone blind spots

Standard cron runs in the server's local timezone. If your server is UTC and you want a job to run at 9am New York time (EST/EDT), you need to account for the offset: 0 14 * * * in UTC for EST (+5), 0 13 * * * for EDT (+4). Daylight saving transitions can cause jobs to shift by an hour.

The "every minute on the 0th minute of an hour" trap

0 * * * * fires once an hour, not once a minute. * * * * * fires every minute. A single 0 in the minute field means "at minute 0 (the top of the hour)."

Jobs that take longer than their interval

If your job takes 45 minutes and runs every 30 minutes, you'll have overlapping runs. Most cron implementations don't enforce single-instance behavior — add a lock file or use flock:

*/30 * * * * flock -n /tmp/myjob.lock /opt/jobs/myjob.sh

Know when your cron jobs stop running

Getting the expression right is half the job. The harder part — and the one that actually causes incidents — is knowing when a scheduled job quietly stops running. Cron doesn't alert you when a job misses its window. It just doesn't run.

The pattern that works: a dead man's switch. Your cron job sends an HTTP ping at the end of each successful run. If the monitoring service doesn't receive the ping within the expected window, it alerts you. One line at the end of your job catches three failure modes at once: the job didn't start, the job failed, or the job was killed before completing.

← All articles  ·  CronWatch  ·  Cron parser tool