Cron Expression Reference for DevOps Jobs

A practical cron schedule reference with common patterns, edge cases, and maintenance checks for DevOps jobs and recurring automation.

Cron syntax looks simple until a backup runs at the wrong hour, a cleanup job fires twice during daylight saving changes, or a cloud scheduler rejects a perfectly valid expression from another system. This reference is designed to be the page you come back to during routine automation work: a practical guide to cron expression examples, common scheduling patterns, portability differences, and the maintenance habits that keep recurring jobs predictable in DevOps environments.

Overview

This guide gives you a working reference for everyday cron usage across DevOps jobs, backups, reporting tasks, maintenance windows, and scheduled automation. It focuses on patterns you are likely to reuse, the edge cases that cause production surprises, and the questions to ask before you save a schedule into a server crontab, Kubernetes CronJob, CI/CD platform, or cloud scheduler.

At its core, traditional cron uses five time fields:

Minute
Hour
Day of month
Month
Day of week

A common layout is:

* * * * * command-to-run

That means:

first *: every minute
second *: every hour
third *: every day of month
fourth *: every month
fifth *: every day of week

Some schedulers extend cron with a seconds field or a year field. Others support special symbols such as ?, L, W, or #. That is where confusion starts: the cron expression that works in one product may fail or behave differently in another.

Before using any expression, confirm three things:

Field count: Is it 5-field cron, 6-field cron, or something vendor-specific?
Time zone: Is the schedule evaluated in local time, UTC, or a separately configured zone?
Execution behavior: If a run overlaps or is missed, does the platform queue it, skip it, or start another copy?

For most teams, cron errors are not syntax errors. They are expectation errors. The expression may parse correctly but still run at the wrong business time, collide with another job, or create resource pressure at the top of the hour.

Common cron building blocks

* = every value
, = list, such as 1,15,30
- = range, such as 1-5
/ = step, such as */10

Examples:

*/5 * * * * = every 5 minutes
0 * * * * = at minute 0 of every hour
0 2 * * * = daily at 02:00
0 2 * * 0 = weekly at 02:00 on Sunday in many cron systems
0 2 1 * * = monthly at 02:00 on the first day of the month

Reference patterns for routine automation

These examples cover many recurring DevOps cron jobs and scheduled task cron patterns:

Every minute: * * * * *
Every 10 minutes: */10 * * * *
At the top of every hour: 0 * * * *
Every day at 01:30: 30 1 * * *
Every weekday at 08:00: 0 8 * * 1-5
Every Sunday at 03:00: 0 3 * * 0
On the first day of every month at 04:15: 15 4 1 * *
Quarterly at midnight on day 1 of Jan, Apr, Jul, Oct: 0 0 1 1,4,7,10 *

Use cases that map well to these patterns include:

rotating logs
syncing reports
rebuilding caches
cleaning temporary files
running non-urgent data pipelines
triggering health checks or low-frequency audits

For production operations, prefer schedules that are easy to read six months later. A slightly longer but obvious expression is often better than a compact one that requires mental decoding during an incident.

Maintenance cycle

This section gives you a repeatable way to maintain cron schedules instead of treating them as one-time setup. If you own scheduled automation, a small review cycle prevents many avoidable failures.

A useful maintenance rhythm is to review cron jobs on a regular operational cadence: monthly for critical jobs, quarterly for standard jobs, and before any major infrastructure, time zone, or platform change. The goal is not to rewrite stable schedules. The goal is to verify that each schedule still matches the system around it.

A practical review checklist

Confirm intent
Ask what the job is supposed to achieve, not just when it runs. “Daily backup” is clearer than “0 2 * * *”.
Verify the execution environment
Check whether the job runs on a Linux host, inside a container, in Kubernetes, in a CI/CD scheduler, or in a managed cloud scheduler. Platform behavior matters.
Check the configured time zone
UTC is usually easier to reason about for infrastructure tasks. Local time may be appropriate for business reports. Either way, document it.
Review overlap behavior
If a job can take longer than its interval, decide whether a second run should be blocked, queued, or allowed. For Kubernetes CronJobs, this often means reviewing concurrency policy.
Inspect failure visibility
A scheduled job that fails silently is more dangerous than a job that never runs. Make sure logs, metrics, and alerts exist for important schedules.
Test edge dates
Monthly and weekday-based jobs deserve extra care around month boundaries, weekends, and daylight saving time changes.
Re-read the expression in plain English
If the team cannot easily explain what it does, rewrite the documentation or simplify the schedule.

Provider and platform differences to watch

There is no single universal cron. Differences show up in several places:

Traditional Unix cron typically uses five fields.
Kubernetes CronJobs commonly use cron-style schedules but the behavior around missed schedules, concurrency, and deadlines depends on Kubernetes settings and controller state.
Cloud schedulers may support alternate field counts, named time zones, or provider-specific validation rules.
Enterprise schedulers and Quartz-style systems often support seconds and special placeholders such as ?.

That means a cron builder guide or online generator is helpful, but only if you select the correct target dialect. Treat every generated expression as a draft until you validate it against the scheduler that will actually run it.

Signals that require updates

This section helps you decide when an existing cron schedule needs attention. Many schedules stay untouched for years, but the systems around them do not.

Revisit a cron job when any of the following signals appear:

1. Platform migration or environment change

If a task moves from a VM crontab to Kubernetes, or from a self-managed host to a cloud scheduler, the expression may still look valid while behavior changes underneath. Time zones, retry behavior, missed-run handling, and permissions all need review.

2. Daylight saving or business time confusion

If stakeholders say “the report arrived an hour late” or “the backup window moved,” check whether the schedule is tied to local time. UTC-based infrastructure jobs are usually simpler. Local-time business jobs may need explicit review before seasonal clock changes.

3. Duration drift

A task that used to finish in three minutes may now run for twenty. That can cause overlap, duplicate work, or lock contention. Scheduled maintenance is not just about syntax; it is about whether the cadence still fits the workload.

4. Load spikes on shared infrastructure

Top-of-hour and midnight schedules create predictable traffic peaks. If you see CPU, API, or database pressure at exact boundaries, stagger jobs. Instead of 0 * * * * for everything, spread jobs across 3, 17, 29, and 43 past the hour.

5. Missed or duplicate executions

These are strong indicators that schedule logic and execution semantics are out of sync. Investigate whether the platform catches up missed jobs, whether clock skew is involved, and whether the task is safe to run more than once.

6. Ownership gaps

If no team clearly owns a scheduled task, it is a maintenance risk. Orphaned cron jobs tend to keep running long after their original purpose is forgotten.

7. Security or credential changes

Scheduled tasks often depend on service accounts, tokens, or rotated secrets. If identity rules change, review cron jobs that call APIs, back up data, or access registries. For teams working with tokens in automation, JWT Decoder Security Guide: What to Check Before You Trust a Token is a useful related read.

8. Search intent and team workflow changes

Even documentation should be refreshed when readers keep asking the same clarifying questions. If engineers repeatedly search for “cron schedule reference” or “cron expression examples” for the same patterns, update your internal guide with plain-English examples and tested snippets.

Common issues

This section covers the mistakes that most often make scheduled jobs unreliable. These are the problems worth checking before assuming the scheduler is broken.

Using the wrong day-of-week convention

Some systems treat Sunday as 0, some accept 7, and some support names like SUN. If portability matters, confirm the accepted values in the target system rather than copying expressions between tools.

Combining day-of-month and day-of-week without understanding the logic

One of the most confusing parts of cron is how these fields interact. In some implementations, a job may run when either field matches rather than only when both match. If you need business rules like “first weekday of the month,” verify whether native cron can express it cleanly in your environment or whether wrapper logic is safer.

Assuming `*/24` means daily

Expressions such as */24 in the hour field do not always mean what people think. For daily jobs, explicit schedules like 0 2 * * * are clearer and less error-prone.

Scheduling too many jobs at the same boundary

Midnight, the top of the hour, and exact five-minute marks are common defaults. They are also common hotspots. Stagger low-priority jobs to reduce resource spikes, especially in shared clusters and busy CI/CD environments.

Ignoring idempotency

Any recurring task should ideally be safe to run more than once. If duplicate execution would corrupt state, add locking, checkpointing, or defensive checks in the task itself. Do not rely only on the scheduler to guarantee single execution.

Forgetting about missed runs

Different systems handle controller restarts, downtime, and delayed scheduling differently. Decide whether catching up is desirable. A missed cleanup job might be safe to skip; a missed billing export may not be.

Not defining a runtime limit

Scheduled tasks that hang can accumulate into bigger incidents than tasks that fail quickly. Set execution timeouts where your platform allows them. This becomes more important when jobs interact with databases, APIs, or external storage.

Assuming cron is enough for complex workflows

Cron is good at timing. It is not a workflow engine. If a process depends on multiple steps, branching logic, approval gates, or durable retries, a more explicit orchestrator may be a better fit than increasingly clever cron expressions.

In Kubernetes, the schedule is only one part of the behavior. Resource requests, job history retention, restart policy, and concurrency settings all influence reliability. If scheduled workloads regularly contend for cluster resources, review your sizing against guidance like Kubernetes Resource Requests and Limits Best Practices by Workload Type.

Weak observability for background tasks

Scheduled jobs often receive less monitoring than user-facing services. Add at least minimal telemetry: start time, finish time, exit code, duration, and failed run counts. If you are standardizing observability for recurring batch work, OpenTelemetry Collectors Explained: Deployment Patterns, Tradeoffs, and Update Guide can help frame collection patterns.

A short plain-English validation habit

Before saving a new expression, read it out loud using this template:

Run at [minute] on [hour] on [day-of-month] in [month] on [day-of-week] in [time zone].

If the sentence sounds awkward or ambiguous, the schedule probably needs simplification or better documentation.

When to revisit

This final section is the practical part: when should you come back to your cron schedule reference, and what should you do each time? Treat cron as operational code that deserves review, not as a set-and-forget checkbox.

Revisit this topic on a regular schedule and during specific change events.

Set a recurring review cadence

Monthly for critical jobs such as backups, certificate automation, exports, and compliance-related tasks
Quarterly for standard maintenance jobs and internal reporting
Before seasonal clock changes if any schedule follows local business time
Before platform migrations involving Kubernetes, CI/CD schedulers, or cloud-native tools

Use a five-minute cron audit

Find the expression and platform.
Confirm the time zone.
Translate it into plain English.
Check last successful run and typical duration.
Verify notifications and logs exist.
Confirm ownership is still current.

Prefer durable scheduling habits

Choose readability over cleverness.
Stagger non-critical jobs.
Use UTC for infrastructure schedules when possible.
Document business-time exceptions.
Make tasks idempotent.
Monitor outcomes, not just trigger events.

Keep a small personal reference

If you regularly work with developer tools online such as a cron builder, JSON formatter, SQL formatter, or regex tester, keep a short saved list of approved cron patterns for your team’s most common use cases. A curated internal reference often prevents more mistakes than a full syntax manual.

As your automation estate grows, cron becomes less about memorizing syntax and more about reducing ambiguity. The expression matters, but so do the surrounding choices: time zone, retry policy, overlap handling, permissions, and observability. Reviewing those details on a maintenance cycle is what turns a fragile schedule into dependable automation.

If you want this page to stay useful, return to it whenever a scheduler changes, a job starts drifting, or your team asks the same scheduling question twice. That is usually the signal that the schedule itself, or the way it is documented, deserves an update.

Cron Expression Reference for DevOps Jobs, Backups, and Scheduled Tasks