Cron Expression Patterns: What Schedules Do Developers Actually Use?

Cron is one of the oldest scheduling systems still in active use — the original Unix cron daemon dates to Version 7 Unix (1979) and the five-field syntax is specified in POSIX.1 (IEEE Std 1003.1). Despite decades of alternatives (systemd timers, Kubernetes CronJobs, cloud schedulers), the five-field cron expression remains the lingua franca of scheduled tasks.

This analysis aggregates cron expression frequency from Stack Overflow questions tagged “cron”, GitHub code search across public repositories, and developer survey responses. The goal is to document what schedules developers actually use in practice — not what is documented in textbooks.

The five-field POSIX cron syntax

Per POSIX crontab(5), a cron expression has five fields:

┌───────────── minute (0–59)
│ ┌───────────── hour (0–23)
│ │ ┌───────────── day of month (1–31)
│ │ │ ┌───────────── month (1–12)
│ │ │ │ ┌───────────── day of week (0–7, where 0 and 7 = Sunday)
│ │ │ │ │
* * * * *

A sixth field (seconds) is not part of the POSIX standard but is supported by many modern schedulers (Spring @Scheduled, Quartz, AWS EventBridge). A seventh field (year) appears in Quartz and some enterprise schedulers. This analysis covers the standard five-field syntax unless noted.

The 20 most common cron patterns

The “every minute” problem

* * * * *is the single most-searched cron expression on Stack Overflow — it appears in the majority of “how do I write a cron expression?” tutorials as the simplest example. This creates a common mistake: developers copy it into production without understanding that it fires 1,440 times per day.

The production risk of every-minute crons:

• Overlapping executions. If the job takes more than 60 seconds, the next instance starts before the first finishes. Without a mutex or idempotency guarantee, two instances can corrupt shared state.
• Thundering herd. Many services deploy with the same * * * * * cron; all instances fire simultaneously at the same wall-clock minute, creating database spikes.
• Silent accumulation. A job that always succeeds but leaves artifacts (temp files, open connections, log entries) will accumulate 2M artifacts per year.

For polling or health-check use cases, */5 * * * *(every 5 minutes) or */15 * * * * (every 15 minutes) is almost always sufficient and 5–15× less resource intensive.

The most production-stable pattern: 0 * * * *

Hourly crons at the top of the hour balance three properties:

1. Low frequency (24/day). If a single run fails or takes longer than expected, there are 23 other runs to recover before the next day.
2. Human-readable.“Runs every hour” is immediately understandable in incident review; “runs every 37 minutes” requires mental math.
3. Aligned to natural aggregation windows. Hourly jobs produce hourly data that aggregates cleanly to daily, weekly, and monthly summaries.

Non-standard extensions to be aware of

Several features commonly seen in cron expressions are not part of the POSIX crontab(5) standard and may not be supported by all schedulers:

• Second field — not POSIX. Supported by Spring @Scheduled, Quartz, GitHub Actions (using the extended syntax). AWS EventBridge uses a six-field format where the first field is minutes, not seconds.
• L (last)— Quartz extension for “last day of month” (L) or “last specific weekday” (5L = last Friday).
• W (nearest weekday) — Quartz extension:15W = nearest weekday to the 15th.
• # (Nth weekday) — Quartz extension:2#3 = third Monday of the month.
• ? (no specific value) — Quartz uses ? in the day-of-month or day-of-week field to avoid the conflict of specifying both. POSIX uses * for both.

When in doubt, test the expression against your target scheduler’s documentation. The POSIX five-field syntax is the safest portable subset.

Timezone traps

POSIX cron runs in the server’s local timezone. “Daily at midnight” (0 0 * * *) means midnight in whatever timezone the server is configured for — which may differ from the user’s timezone, the data’s timezone, or the business’s timezone. UTC servers are the least surprising; if you need local-time semantics, use a scheduler that supports named timezones (systemd timers’ OnCalendar with TimeZone=, Kubernetes CronJob spec.timeZone, AWS EventBridge schedule expressions with timezone).

Daylight Saving Time adds a further complication: twice a year, local midnight is either skipped (spring forward) or occurs twice (fall back). A daily-at-midnight cron may run zero times or twice on DST transition days in affected timezones.

Methodology note

Frequency rankings are derived from: Stack Overflow question and accepted-answer analysis for questions tagged “cron” (2010–2025, ~38K questions); GitHub public repository code search for crontab files and cron string literals in YAML/JSON CI configurations; and the Stack Overflow Developer Survey 2024 (infrastructure/DevOps tooling section). Absolute counts are not disclosed as the underlying datasets are subject to sampling bias. Rankings reflect relative frequency, not absolute volume.

Sources

POSIX.1-2017 crontab(5) specification (opengroup.org); Quartz Scheduler CronExpression documentation (quartz-scheduler.org); Stack Overflow Developer Survey 2024 (survey.stackoverflow.co); GitHub code search, public repositories, June 2026; AWS EventBridge scheduled expressions documentation (docs.aws.amazon.com).