Cron Expression Generator Guide: Schedule Jobs Without Errors

Understanding the Five (and Six) Fields

A standard cron expression has five space-separated fields:

┌───────── minute (0–59)
│ ┌─────── hour (0–23)
│ │ ┌───── day of month (1–31)
│ │ │ ┌─── month (1–12 or JAN–DEC)
│ │ │ │ ┌─ day of week (0–6, 0=Sunday, or SUN–SAT)
│ │ │ │ │
* * * * *

Some systems (Kubernetes CronJobs, AWS EventBridge, many schedulers) add a sixth field for seconds:

┌─────────── second (0–59)
│ ┌───────── minute (0–59)
│ │ ┌─────── hour (0–23)
│ │ │ ┌───── day of month (1–31)
│ │ │ │ ┌─── month (1–12)
│ │ │ │ │ ┌─ day of week (0–6)
│ │ │ │ │ │
* * * * * *

Our generator supports both formats. Always confirm which format your target system uses before deploying — a 6-field expression on a 5-field system will fail silently or throw a parse error.

Special Characters

Common Schedules Reference

# Every minute
* * * * *

# Every hour (at the top of the hour)
0 * * * *

# Every day at midnight UTC
0 0 * * *

# Every day at 8am
0 8 * * *

# Every weekday (Monday–Friday) at 9am
0 9 * * 1-5

# Every Monday at 9am
0 9 * * 1

# Every Sunday at 2am (good for weekly maintenance)
0 2 * * 0

# Every 15 minutes
*/15 * * * *

# Every 6 hours
0 */6 * * *

# First day of every month at midnight
0 0 1 * *

# Every quarter (Jan, Apr, Jul, Oct) on the 1st at midnight
0 0 1 1,4,7,10 *

# Every weekday at 8am, 1pm, and 6pm
0 8,13,18 * * 1-5

# Last day of every month at 11:59pm
59 23 L * *

The @ Shorthand (Supported by Many Systems)

Some schedulers support named shortcuts:

Common Mistakes and Gotchas

Day of month vs Day of week conflict

When you specify both day of month AND day of week (both non-*), most Unix cron implementations use OR logic — the job runs if either condition matches. This surprises developers who expect AND logic.

# Runs on the 15th of the month OR every Friday — not "every Friday the 15th"
0 0 15 * 5

To get "the 15th only if it's a Friday," you need application-level logic, not cron alone.

Month 0 vs Month 12

Standard cron uses 1–12 for months. Some systems use 0–11 (JavaScript-style). Verify with your scheduler.

Day of week 0 vs 7 for Sunday

Most systems accept both 0 and 7 as Sunday. Some don't. Using SUN (the text name) is more portable.

Timezone is the server's timezone

Standard cron runs in the system's local timezone. If your server is UTC and you want a job at "9am business hours," the expression depends on the server's configured timezone — not your local time.

Modern solutions:

• Kubernetes CronJobs: set spec.timeZone: "America/New_York"
• AWS EventBridge: supports IANA timezone in schedule expressions
• GitHub Actions: schedule cron always runs in UTC

Always document the timezone assumption next to every cron expression in your code.

"Every 30 minutes" is not 30 * * * *

# Wrong — runs at :30 past every hour (once per hour, not every 30 min)
30 * * * *

# Correct — runs at :00 and :30 of every hour
*/30 * * * *
# or equivalently:
0,30 * * * *

Jobs overlapping

If your job takes longer than its interval, multiple instances accumulate. A job scheduled every minute that takes 90 seconds will have two instances running simultaneously by the second cycle. Solutions:

• Add a lock file or mutex (flock, Redis SETNX)
• Use a job scheduler (Sidekiq, Celery, Temporal) instead of raw cron
• Set the interval longer than the maximum expected duration

Validating Next Run Times

After building an expression, always verify the next 5–10 scheduled times. Our generator shows a live English translation and next-run preview — "runs every Tuesday and Thursday at 3:00 AM UTC" is immediately verifiable. Compare against the schedule you intended.

Use our Timestamp Converter to translate next-run Unix timestamps to your local time when cross-referencing with other systems or verifying across timezones.

Scheduling Automated Tasks

Cron is commonly used to schedule:

• Database backups — 0 2 * * * (2am daily, off-peak)
• Certificate renewal — 0 0 * * * (daily check, Let's Encrypt recommends twice daily: 0 0,12 * * *)
• Report generation — 0 8 * * 1 (Monday morning, before business hours)
• Cache warming — */5 * * * * (every 5 minutes)
• Log rotation — 0 0 * * * (daily midnight)
• Docker pruning — 0 3 * * 0 (Sunday 3am)

For Docker maintenance specifically, combine cron expressions with our Dockerfile Generator to build the containerized jobs that cron will invoke.

Testing Before Deploying

The worst time to discover a cron mistake is after deploying to production. Test your expressions with:

1. The live translation in our generator ("runs every 15 minutes")
2. A next-run list (does it show the times you expect?)
3. A manual test run of the underlying script before letting cron invoke it

Use our cURL Generator to test the HTTP endpoints your cron jobs call — validate response codes and payloads before trusting the scheduled invocation. Document the cron job purpose, schedule, and expected behavior in your runbooks using our Markdown Editor.