Cron Expressions Explained: Read Schedules and Convert Cron to Time

You paste a cron expression into a YAML file, a GitHub Actions workflow, or a crontab, then wonder whether 0 9 * * 1-5 really means weekdays at 9 AM in your timezone. Decode the expression and check the next few run times before you ship it.

Use the Cron to Time Converter to turn any five-field cron string into plain language and upcoming execution times. If you know the schedule but not the syntax, start with Time to Cron instead.

The five fields (minute to weekday)

Standard cron uses five space-separated fields:

* * * * *
│ │ │ │ └── day of week (0-6, Sunday = 0 on most systems)
│ │ │ └──── month (1-12)
│ │ └────── day of month (1-31)
│ └──────── hour (0-23)
└────────── minute (0-59)

Special characters you will see everywhere:

Some platforms (AWS EventBridge, Spring, etc.) add a seconds field or use different weekday numbering. Check your scheduler docs first. GitHub Actions, Linux crontab, and many K8s CronJobs follow the table above.

Examples worth memorizing

Paste these into the Cron to Time Converter to see the next runs:

Every day at 9:00 AM

0 9 * * *

Every 5 minutes

*/5 * * * *

Weekdays at 9:00 AM (Monday-Friday)

0 9 * * 1-5

Every Monday at 2:30 AM

30 2 * * 1

First day of every month at midnight

0 0 1 * *

Every 15 minutes during business hours on weekdays

*/15 9-17 * * 1-5

If the readable description or next-run list looks wrong, fix the expression before merging. You do not want to find out at 3 AM on a Sunday.

Quick workflow before you deploy

1. Paste your cron expression into Cron to Time.
2. Confirm the human-readable summary matches what you intended.
3. Scan the next 5-10 execution times for surprises (weekends, gaps, double runs).
4. Note which timezone the scheduler uses (see below).
5. Need the expression from a plain-English schedule? Use Time to Cron, then loop back to step 1.

Common mistakes (and how to avoid them)

• Timezone drift. Cron runs in the server or platform timezone unless configured otherwise. A 0 9 * * * job on a UTC server is not 9 AM in New York. Check GitHub Actions schedule (UTC), your VPS /etc/timezone, or K8s controller settings. Use the Timezone Converter when comparing local time to UTC.
• Day-of-month vs day-of-week. On classic Vixie cron, specifying both day-of-month and day-of-week often means or, not and. Expressions like 0 9 1 * 1 confuse people. Prefer one field when you can (0 9 1 * * for monthly, 0 9 * * 1 for weekly).
• Off-by-one weekdays. Most Linux cron uses 0 = Sunday. Some UIs label Monday as 1. When in doubt, verify with the converter’s next-run list.
• Copy-paste from the wrong doc. Quartz, AWS, and Kubernetes CronJob examples are not always interchangeable. Six-field cron or ? wildcards belong to other dialects.

Where cron shows up in real projects

• Linux crontab: crontab -e on a VPS or container host.
• GitHub Actions: on: schedule: - cron: '0 9 * * 1-5' (always UTC).
• Kubernetes: CronJob spec schedule: field in manifest YAML.
• CI/CD and backups: nightly dumps, cache warming, report generation.

For date math around a schedule (e.g. “runs on the 15th, but what if the month has 30 days?”), pair cron checks with the Date Calculator.

When to use something else

• One-off run at a specific timestamp: use your platform’s “run once” or a calendar trigger, not cron.
• Sub-minute precision: standard cron is minute-granularity; use a worker loop or a scheduler that supports seconds.
• Complex rules (“last Friday of the month”): some teams use a real scheduler (Temporal, Airflow) instead of clever cron.