What is a cron expression?

A cron expression is a compact scheduling string used to describe when periodic tasks should run. Different platforms support slightly different field counts, but the core idea is the same: each field progressively narrows down the exact moments a task will execute. Unix cron uses 5 fields (minute, hour, day, month, weekday), while Quartz cron adds a seconds field for a total of 6.

When should I use Quartz mode vs. Unix mode?

For Linux crontab, Kubernetes CronJobs, and most traditional cron environments, use Unix mode. If your system explicitly requires a seconds field — such as Spring Boot's @Scheduled annotation, Quartz Scheduler, Elastic Job, and other Java ecosystem scheduling frameworks — use Quartz mode. When in doubt, consult your framework's official documentation.

Why does Quartz often use the ? symbol?

Quartz treats "day of month" and "day of week" as two separate sets of constraints. When one field already defines the scheduling rule, the other is often set to ? to indicate it should not participate in matching. For example, "every Monday at 8 AM" should be written as 0 0 8 ? * MON — the day-of-month field uses ? instead of * to avoid a semantic conflict.

Can I treat the predicted execution times as authoritative?

They are intended for quick pre-deployment verification to help you catch obvious expression problems. For platform-specific advanced syntax extensions, we still recommend a final test in your target scheduler.

Are crontab and Kubernetes CronJob cron expressions the same?

The core syntax is the same — both use the Unix 5-field format. However, Kubernetes CronJobs do not support crontab's environment variables or special strings (such as @reboot, @daily), and the starting schedule is calculated from the Job's creation time. If your CronJob runs across clusters in different time zones, also pay attention to the spec.timeZone setting.

What is the difference between * and ? — when should I use each?

* means "every possible value of this field will match," while ? means "I don't care about this field — do not use it for matching." In Quartz, the day-of-month and day-of-week fields cannot both be set to *, because two overlapping * values create unintended intersection logic — one of them must be set to ? instead. Unix cron does not have ?, it only supports *.

My cron job isn't running on schedule. How do I troubleshoot?

We recommend the following steps: 1) Verify the server timezone (use the date command); 2) Check whether the cron service is running (systemctl status cron/crond); 3) Inspect system logs (grep CRON /var/log/syslog); 4) Confirm the script has execute permissions; 5) Paste your expression into this tool and check whether the semantic interpretation matches your expectations — field order reversal is the most common root cause.

Does cron support sub-minute scheduling (e.g. every X seconds)?

Standard Unix cron has a minimum granularity of one minute and does not support second-level scheduling. If your workload requires sub-minute or second-level intervals, consider these alternatives: use an in-code timer (e.g. Java ScheduledExecutorService), adopt a dedicated scheduling framework (Quartz supports second-level precision), or run a long-lived process with a sleep loop.

How do I configure scheduled triggers in GitHub Actions?

GitHub Actions scheduled triggers use the standard Unix 5-field format, configured via the on.schedule.cron field in your workflow YAML. Two important caveats: the timezone is always UTC with no exceptions; and during high-load periods (especially popular time slots like the top of the hour), actual trigger times may lag behind the schedule by 15–30 minutes or more. For time-sensitive jobs, consider supplementing with repository_dispatch events or a third-party scheduling service.

When multiple cron jobs fire simultaneously, how do I prevent resource contention?

The simplest approach is intentional time-staggering: spread adjacent jobs across different minutes rather than scheduling everything at minute 0. For jobs that must be mutually exclusive, use flock for file-based locking on Linux, or a Redis SET NX pattern for distributed environments. In Kubernetes, the CronJob concurrencyPolicy field offers three options: Allow (default, concurrent runs permitted), Forbid (skip the new run if the previous one is still running), and Replace (terminate the old run and start a new one). For most batch workloads, Forbid is the safest choice.

Back to Tools

Guest: 5 / 5 uses left today Sign In

For Scheduling & Automation

Cron Expression Generator

Switch between Quartz 6-field and Unix 5-field modes, quickly build deployable cron expressions, and preview upcoming execution times.

CRON

0 */5 * * * ?

6 fields: Sec Min Hour Day Month Week

Best for Spring / Quartz schedulers that require a seconds field.

Raw Expression

Paste an existing cron expression to load it back into the builder.

Quartz mode requires 6 fields, e.g.: 0 */5 * * * ?

Schedule Builder

Edit fields directly if you know the syntax, or start from a preset.

Sec0-59, *, step, range, list

Min0-59, *, step, range, list

Hour0-23, *, step, range, list

Day of Month1-31, *, ?, step, range, list

Month1-12 or JAN-DEC

Day of Week0-7 or SUN-SAT

Syntax Overview

The patterns below cover the majority of production cron scenarios.

*/5

Step Values

e.g., */5 means execute every 5 units. Commonly used for every-N-minutes schedules.

1-5

Range

e.g., 1-5 represents a continuous interval. Useful for weekday or month ranges.

MON,WED,FRI

List

e.g., MON,WED,FRI matches multiple discrete values.

?

Unspecified

Quartz uses ? to indicate a field that should not participate in matching, avoiding day-vs-week conflicts.

Natural Language Interpretation

Runs every 5 minutes

Platform Compatibility Tips

Quartz mode is for schedulers with a seconds field, such as Spring / Quartz. If you deploy to Linux or Kubernetes, switch to Unix mode first and re-verify the expression.

Next 5 Execution Times

#1Jun 12, 2026, 15:55:00

#2Jun 12, 2026, 16:00:00

#3Jun 12, 2026, 16:05:00

#4Jun 12, 2026, 16:10:00

#5Jun 12, 2026, 16:15:00

Field Reference

Sec0-59

Controls the seconds value within a minute. Quartz mode only.

Min0-59

Controls the minutes value within an hour.

Hour0-23

Controls the hour value in 24-hour format.

Day of Month1-31

Controls the day of the month. In Quartz, often paired with ? in the week field.

Month1-12 or JAN-DEC

Controls the month. Accepts numeric values or month abbreviations.

Day of Week0-7 or SUN-SAT

Controls the day of the week. Accepts numeric values or day abbreviations.

Special Characters

*

Wildcard

Matches all possible values for that field.

*/n

Step

Repeats at a fixed interval, e.g., every 5 minutes.

a-b

Range

Matches all continuous values between the start and end boundaries.

a,b,c

List

Matches multiple explicit values within the same field.

?

Unspecified

Quartz-only. A placeholder indicating that the field does not participate in schedule matching.

Common Schedule Templates

Start from real-world scenarios rather than six blank fields.

What problem does this Cron page solve?

Cron syntax is short, but the cost of getting it wrong is high. A single misplaced field can silently change "every 5 minutes" to "once a month." This page is designed to shorten the debugging loop: build the expression and immediately see the final result and predicted execution times.

The page supports both Unix 5-field and Quartz 6-field modes, so it works for Linux servers, Kubernetes CronJobs, and Spring / Quartz schedulers that require a seconds field.

How to use this tool

First, choose the cron mode that matches your target platform, then either start from a preset or edit each field directly. The expression updates immediately. If you already have a cron string, paste it into the "Raw Expression" area to load it back into the builder for inspection.

Before deploying, always read the natural-language interpretation and verify that the next 5 execution times match your expectations. This step is the most effective way to catch field-order errors, day-of-week misunderstandings, and platform mode mismatches.

Pre-Deployment Notes

Cron trigger times always depend on the timezone of the scheduler host. Verify the server timezone before deployment. In Kubernetes CronJobs, the default is UTC — use spec.timeZone to set it explicitly.
Unix cron and Quartz cron are not interchangeable by default. Confirm whether the target platform expects 5 or 6 fields. Using the wrong mode will cause jobs to either not run or run at unexpected frequencies.
In Quartz, the day-of-month and day-of-week fields are often paired with ? to prevent both fields from constraining the schedule simultaneously. Unix cron does not support ? — if either field matches, the job triggers.
This page covers the most common cron syntax. If your platform supports specialized extensions (such as @yearly, L, W, etc.), we recommend a final test in the target environment.
When writing cron expressions in shell scripts or YAML, be mindful of special characters like * and /. In Kubernetes CronJob YAML, wrap the expression in quotes to prevent the YAML parser from misinterpreting them.
When deploying a new cron job for the first time, start with "every minute" as a temporary test to confirm the job itself runs correctly, then switch to your actual desired schedule.

Typical Production Scenarios

The following are the most common scheduling patterns in DevOps practice. Use the expressions as a direct reference or adapt them to your specific needs.

Nightly CI/CD Build

Quartz: 0 0 2 * * ?Unix: 0 2 * * *

Trigger a full build or integration test run during off-peak hours (typically 2 AM) to avoid competing for CI runner capacity during the day. If the build is long-running, set a job-level timeout to prevent a hung build from blocking subsequent runs and exhausting your CI queue.

Full Database Backup

Quartz: 0 30 1 * * ?Unix: 30 1 * * *

Run a full backup at 1:30 AM, ensuring it completes and its integrity is verified before the morning traffic peak. Combine with --single-transaction (MySQL) or pg_dump for a consistent snapshot. Always emit a confirmation log or alert — never rely on the script running without verifying the result.

SSL Certificate Auto-Renewal

Quartz: 0 0 3 * * ?Unix: 0 3 * * *

Let's Encrypt certificates expire after 90 days; certbot only performs renewal when fewer than 30 days remain. Running daily at 3 AM is safe — most runs are no-ops, and the actual renewal only triggers near expiry. After a successful renewal, reload or restart your web server (e.g. nginx -s reload) to apply the new certificate immediately.

Log Rotation & Archiving

Quartz: 0 5 0 * * ?Unix: 5 0 * * *

Scheduling at 00:05 instead of 00:00 avoids resource contention with other top-of-hour jobs and gives the system a 5-minute buffer to finish writing the previous day's logs before rotation begins. In practice, this is commonly paired with the logrotate utility — logrotate handles the file splitting, cron handles the scheduling.

Cache Warm-Up

Quartz: 0 50 7 * * 1-5Unix: 50 7 * * 1-5

For workloads that spike at 8 AM on weekdays (e.g., B2B SaaS platforms, internal enterprise tools), triggering a cache warm-up script at 07:50 — 10 minutes early — can significantly reduce cache miss rates and peak database load during the morning rush. Limiting to weekdays (1-5) avoids unnecessary resource consumption on weekends.

Periodic Health Check

Quartz: 0 */5 * * * ?Unix: */5 * * * *

Sending an HTTP probe or TCP check to critical services every 5 minutes is the most fundamental availability monitoring approach. A self-hosted health-check script can run entirely within a private network without any public internet dependency — ideal for air-gapped or private-cloud deployments. Ensure your alerting pipeline includes deduplication to avoid flooding on-call with repeated alerts from transient blips.

Common Cron Expression Examples (Cheat Sheet)

Here are the most frequently searched cron expression patterns (all in Unix 5-field format). Copy them directly, or paste them into the builder above to see the plain-English explanation and the next run times.

Every 5 minutes

*/5 * * * *

*/5 makes the minute field fire every 5 units — the most common frequency for health checks, probes, and lightweight polling. Change it to */10 or */15 for every 10 or 15 minutes.

Every hour, on the hour

0 * * * *

Minute 0 and hour * fires once at the top of every hour, commonly used for hourly aggregation and cache refresh. Every 2 hours is 0 */2 * * *.

Every day at midnight

0 0 * * *

0 0 fires daily at 00:00, ideal for day-grained batch jobs. Equivalent to crontab's @daily.

Every day at 2 AM

0 2 * * *

The classic off-peak time for full backups and nightly builds, avoiding daytime peak resource usage.

Weekdays at 9 AM

0 9 * * 1-5

The weekday field 1-5 means Monday through Friday, skipping weekends. Great for workday reports and pre-shift cache warm-up.

Every Monday at 8 AM

0 8 * * 1

The weekday field 1 means Monday (both 0 and 7 mean Sunday). Commonly used for weekly reports and weekly cleanup tasks.

On the 1st of every month

0 0 1 * *

The day field 1 fires at 00:00 on the first day of each month — ideal for monthly billing and start-of-month archiving. Equivalent to @monthly.

Every Sunday at midnight

0 0 * * 0

The weekday field 0 means Sunday, commonly used for weekly full backups and weekend maintenance-window tasks.

Timezone Pitfalls Explained

Cron has no built-in concept of timezones — trigger times are determined entirely by the system clock of the machine running the scheduler. This is one of the most common root causes of silent scheduling bugs in containerized and multi-region deployments: you write "8 AM," the server interprets it as "UTC 8 AM," and the actual trigger time ends up being 4 PM in your local timezone.

Docker containers inherit the host's timezone by default, but most cloud instances (AWS EC2, GCP Compute Engine, Alibaba Cloud ECS) ship configured to UTC, not your local timezone. Before deploying, confirm the current system time with date and inspect the full timezone configuration with timedatectl — both checks are necessary.

Kubernetes versions prior to v1.27 forced all CronJobs to use UTC with no timezone option. v1.27+ officially introduced the spec.timeZone field, which accepts standard IANA timezone identifiers such as Asia/Shanghai or America/New_York. If your cluster predates v1.27, the only workaround is manually offsetting the expression for the UTC difference — and documenting that offset in comments so future maintainers don't silently revert it.

Daylight Saving Time (DST) introduces another class of subtle bugs: when clocks spring forward, any time between 2:00 AM and 3:00 AM simply does not exist on that day — cron jobs scheduled in that window will be silently skipped. When clocks fall back, the window repeats and jobs may fire twice. For production-critical tasks, schedule them before 1:00 AM or after 3:30 AM to avoid the DST ambiguity zone entirely.