Cron Expression Examples Explained

Reference tables of cron expressions are everywhere on the web. The problem is that they rarely tell you when to use a particular schedule, why it's structured the way it is, or what can go wrong. This guide walks through the most common cron patterns I have used and reviewed in production over the past decade, with the context that turns each expression from a copy-paste snippet into a deliberate scheduling decision.

All examples use the standard 5-field Unix cron format (minute, hour, day-of-month, month, day-of-week), which is what Linux crontab, Kubernetes CronJobs, and GitHub Actions accept. If you are working with Java Quartz or Spring Boot, see the Quartz cron guide for the 6-7 field variant.

Short-Interval Polling Schedules

Short intervals are useful when you need to react quickly to external state changes — health checks, queue draining, cache refreshes, or webhook retries. The trade-off is load: a job that runs every minute generates 1,440 invocations per day, so even small per-run costs add up.

A common mistake with short intervals is forgetting that all minute marks fire at the same wall-clock instant across every host. If you have ten replicas of a CronJob, all ten will start at exactly :00 of each minute, often hammering the same downstream service. For high-frequency polling, prefer a queue worker, an event-driven trigger, or jitter the schedule with sleep at the start of the script.

Daily Maintenance Schedules

Most production cron jobs run once a day during off-peak hours. The exact time matters more than people realize: in a global SaaS, "midnight" in your timezone might be peak traffic in another region. A reliable rule of thumb is to schedule maintenance jobs during your application's lowest-traffic window, not during your team's sleeping hours.

Daily backups are the canonical example. 0 2 * * * at 2:00 AM is popular because it sits after most US/EU traffic dies down but before European workers start. On Kubernetes, double-check your .spec.timeZone value (introduced in 1.27) — without it, jobs run in the kube-controller-manager timezone, which is almost always UTC. A schedule of 0 2 * * * in UTC is 6:00 AM Istanbul time, which is far from off-peak.

Business-Hours Schedules

Business-hours schedules combine the day-of-week and hour fields. The pattern * * * * 1-5 means "Monday through Friday" (the 1-5 range maps to Mon-Fri in standard Unix cron). Use these for jobs that should only operate during office hours: email digests, internal reports, on-call notifications, or anything that would be wasted CPU on a weekend.

A subtle gotcha: 0 9-17 * * 1-5 fires at 9:00, 10:00, …, 17:00. That includes 5:00 PM on the dot, which might be after your team has logged off. To stop at 4:00 PM, use the upper bound 9-16. Cron ranges are inclusive on both ends, which catches everyone off guard the first time.

Weekly & Monthly Rotations

Weekly and monthly schedules are great for heavier work that doesn't need to run daily — full database backups, log archives, certificate renewals, or report generation. Be careful with 0 0 1 * * (first of every month): it will not fire on February 29 if you change it to 0 0 29 * *, and it will silently skip months that don't have a 31st if you use 0 0 31 * *.

The Unix cron interpretation of day-of-month and day-of-week is unusual: when both are set to specific values (anything other than *), the schedule fires when either matches, not both. So 0 0 13 * 5 fires on the 13th of every month and every Friday — usually not what people expect when reading "Friday the 13th". To require both, you need Quartz with the ? wildcard or post-process in your script.

DevOps & Site Reliability Schedules

The patterns below come up constantly in DevOps work — health checks, log rotation, certificate monitoring, deployment freezes, and so on. They are simple expressions but carry a lot of operational weight. A misfired backup or a stuck health check can cascade into real outages.

Always pair production cron jobs with monitoring. A schedule firing successfully is not the same as a job completing successfully. Consider a dead-man's switch (Healthchecks.io, Cronitor, or a simple metric increment) so that you get paged when a job fails to run, not just when it errors. For a deeper dive into running cron jobs in production, see our cron best practices guide and troubleshooting reference.

Frequently Asked Questions