Cron Expressions Explained: A Complete Guide to Scheduling Jobs

Cron is the de facto language for recurring schedules on servers and in automation platforms. Whether you are rotating logs at midnight, triggering backups, or running a nightly data pipeline, cron expressions turn a compact string into a precise timetable. This guide walks the classic five-field format, the punctuation that modifies it, and how modern CI systems adapt the same ideas — with tooling like ToolPilot's cron expression builder to validate what you write.

What is cron?

Originally tied to the Unix cron daemon, "cron" now refers both to the scheduler and the mini-language describing when jobs run. A user or system defines a schedule string; the scheduler wakes the command or webhook at those instants. Cron excels at repetitive maintenance — cache warming, certificate renewal checks, report generation — while one-off tasks are often better as queued jobs or manual runs.

The five-field format

The most common Unix-style cron expression has five fields, read left to right:

1. Minute (0–59)
2. Hour (0–23)
3. Day of month (1–31)
4. Month (1–12 or names)
5. Weekday (0–7, where 0 and 7 often both mean Sunday — check your platform's docs)

Some systems add a seconds field or use six fields including seconds; always read the product documentation when moving cron expressions between environments. A mismatch there is a frequent source of "runs at the wrong time" bugs.

Special characters: *, /, -, and comma

• Asterisk (*): every valid value in that field — "any" minute, hour, etc.
• Slash (/): steps;*/5 in the minute field means every five minutes.
• Hyphen (-): ranges;9-17 in the hour field covers 9am through 5pm.
• Comma (,): lists;1,15 on day-of-month runs on the 1st and 15th.

When day-of-month and weekday are both restricted (neither is*), many implementations treat the job as matching either condition — another detail to confirm per engine.

Common cron patterns

• Every 5 minutes: */5 * * * *
• Daily at midnight (server local): 0 0 * * *
• Weekly on Monday at 09:00: 0 9 * * 1 (if Monday = 1 in your environment).
• Monthly on the 1st at 06:30: 30 6 1 * *

Copy-paste patterns only after verifying weekday numbering and whether the platform uses UTC or the runner's local timezone.

Cron in CI/CD: GitHub Actions and GitLab CI

Continuous integration systems reuse cron syntax for scheduled workflows. GitHub Actions schedule triggers accept cron expressions in UTC. GitLab CI scheduled pipelines similarly interpret cron strings on the server side. That means your "9am" job might be 9am UTC unless you offset the hours in the expression or configure a runner timezone explicitly.

Keep CI schedules idempotent: if a nightly job overlaps a deployment, use locks or queue semantics so double-fires from manual re-runs do not corrupt data. Pair schedules with observability so missed runs surface as alerts, not silent gaps.

Timezone considerations

Server cron typically uses the machine's local timezone; cloud schedulers often standardize on UTC. Daylight saving shifts can make "2:30am every day" ambiguous — some local times do not exist or occur twice when clocks change. For global products, UTC plus explicit user-facing labels tends to be clearer than scattering implicit local zones across cron expressions.

When correlating logs with external APIs, convert instants with a timestamp converter so incident timelines line up across systems.

Testing cron expressions

Before promoting a schedule to production, enumerate the next several run times with a trusted parser, run the job in a staging environment, and watch for off-by-one weekday or month errors. Document the intended timezone next to the expression in your infrastructure repo so future edits preserve meaning.

For payload-heavy automations, validate JSON configs and webhook bodies with ToolPilot's JSON formatter before they are embedded in scheduled tasks — syntax errors should fail in preview, not at 2am on Saturday.