Cron Expressions Demystified: Schedule Tasks Like a Pro

Published on December 8, 2025 · 10 min read

What Is Cron and Why Does It Matter?

If you have ever needed a script to run at 3 AM every night, a database backup to fire every Sunday, or a report to generate on the first of each month, you have encountered the need for scheduled task automation. On Unix-like systems, the tool that handles this is called cron, and the language it speaks is the cron expression.

Cron has been a fundamental part of system administration since the 1970s, but its expression syntax has spread far beyond Unix. Today, cron expressions are used in CI/CD pipelines (GitHub Actions, GitLab CI), cloud schedulers (AWS EventBridge, Google Cloud Scheduler, Azure Functions), job queues (Celery, Sidekiq, Quartz), container orchestration (Kubernetes CronJobs), and countless web frameworks. Understanding cron syntax is not just a sysadmin skill -- it is a core competency for any developer who builds systems that need to do things on a schedule.

The challenge is that cron expressions look cryptic at first glance. A string like 15 9 1,15 * 1-5 packs a lot of meaning into very few characters. This guide will break down every piece so you can read, write, and debug cron expressions with confidence.

The 5-Field Format Explained

A standard cron expression consists of exactly five fields separated by spaces. Each field controls one dimension of the schedule:

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

Field 1: Minute (0-59)

This controls which minute of the hour the task fires. Setting it to 0 means the task runs at the top of the hour. Setting it to 30 means it runs at the half-hour mark. Using * means every minute -- which is rarely what you want for most jobs, but useful for monitoring scripts that need near-real-time checks.

Field 2: Hour (0-23)

This uses a 24-hour clock. 0 is midnight, 12 is noon, and 23 is 11 PM. One important detail: cron always uses the server's local timezone unless your cron implementation explicitly supports timezone configuration. This matters enormously when your servers are in UTC but your users are in different time zones.

Field 3: Day of Month (1-31)

Specifies which day of the month the task should run. Be careful with values like 31 -- months with fewer days will simply skip the execution, which may or may not be what you intend. February is the most common source of surprises here.

Field 4: Month (1-12)

Controls which months the task is active. You can use numeric values (1 for January through 12 for December) or, in many implementations, three-letter abbreviations like JAN, FEB, MAR. Numeric values are more portable across different cron implementations.

Field 5: Day of Week (0-7)

Determines which days of the week the task runs. Both 0 and 7 represent Sunday, 1 is Monday, through 6 for Saturday. Some implementations also accept MON, TUE, etc. When both the day-of-month and day-of-week fields are set to specific values (not *), most cron implementations will run the task when either condition is met, not when both are met. This is one of the most common sources of confusion.

Special Characters and What They Mean

Beyond plain numbers, cron expressions support several special characters that give you fine-grained control over scheduling.

Asterisk (*) -- Every Value

The asterisk is a wildcard meaning "every possible value" for that field. * * * * * means every minute of every hour of every day. It is the simplest expression and also the most aggressive -- use it carefully.

Comma (,) -- Value Lists

Commas let you specify multiple discrete values. 0,15,30,45 * * * * means the task runs at minute 0, 15, 30, and 45 of every hour -- effectively every 15 minutes, but with explicit control over which minutes.

Hyphen (-) -- Ranges

Hyphens define inclusive ranges. 0 9-17 * * * means "at the top of every hour from 9 AM to 5 PM." This is cleaner than listing every hour with commas and easier to read at a glance.

Slash (/) -- Step Values

The slash defines intervals. */10 * * * * means "every 10 minutes" starting from 0 (so minute 0, 10, 20, 30, 40, 50). You can also combine slashes with ranges: 5-55/10 * * * * means every 10 minutes starting at minute 5 (so 5, 15, 25, 35, 45, 55).

Combining Characters

These characters can be combined within a single field. For example, 0,30 9-17 * * 1-5 means "at minutes 0 and 30 of every hour between 9 AM and 5 PM, Monday through Friday." This is a typical business-hours schedule that runs twice per hour during the workday.

Common Scheduling Patterns

Certain scheduling needs come up again and again in software projects. Here are the patterns you will reach for most often, along with the reasoning behind each one.

Every Day at Midnight

0 0 * * *

The classic daily job. Database cleanups, log rotation, daily report generation, and cache invalidation are all common midnight tasks. Choose midnight because system load is typically lowest, but remember that "midnight" depends on your server's timezone.

Every Weekday at 9 AM

0 9 * * 1-5

Ideal for business-oriented automation: sending daily digest emails, pulling metrics dashboards, or triggering CI builds for the day's work. The 1-5 in the day-of-week field covers Monday through Friday.

Every 5 Minutes

*/5 * * * *

Common for health checks, queue processors, and lightweight monitoring. Before using this, ask yourself if you truly need 5-minute resolution or if 15 or 30 minutes would suffice. Frequent cron jobs add load and can stack up if a previous run has not finished.

First Day of Every Month at 6 AM

0 6 1 * *

Monthly billing runs, invoice generation, subscription renewals, and compliance reports often follow this pattern. Running at 6 AM rather than midnight gives you a buffer in case overnight maintenance ran long.

Every Sunday at 2 AM

0 2 * * 0

Weekly maintenance windows, full database backups, and dependency update checks fit naturally into a Sunday early-morning slot. Be cautious about daylight saving time transitions -- 2 AM is when many DST changes happen, which can cause the job to run twice or not at all.

Every Quarter (First Day of Jan, Apr, Jul, Oct)

0 8 1 1,4,7,10 *

Quarterly financial reports, performance reviews, and compliance audits. Listing months explicitly with commas is the cleanest way to express quarterly schedules.

Real-World Scheduling Examples

Let's walk through scenarios that go beyond textbook examples, because production systems rarely need something as simple as "run daily."

E-Commerce: Abandoned Cart Emails

0 10,14,18 * * *

This runs at 10 AM, 2 PM, and 6 PM daily. The logic here is behavioral: you check for carts abandoned in the last few hours and send reminder emails at times when users are likely to be online. Running once per day would mean some carts sit untouched for nearly 24 hours; running every few minutes wastes resources since email delivery does not need to be real-time.

DevOps: Staggered Health Checks Across Services

*/2 * * * *    (Service A)
1-59/2 * * * * (Service B)

Service A runs on even minutes (0, 2, 4...) while Service B runs on odd minutes (1, 3, 5...). Staggering prevents all health checks from hitting your monitoring infrastructure simultaneously, which can itself cause false positives under load.

Data Pipeline: Sequential ETL Steps

0 1 * * *   (Extract)
30 1 * * *  (Transform)
0 2 * * *   (Load)

Rather than running the entire ETL pipeline in one monolithic job, breaking it into 30-minute increments gives each step time to complete and makes debugging failures much easier. If the Extract step fails, the Transform and Load steps will simply have no new data to process rather than crashing mid-pipeline.

SaaS Platform: Free-Tier Usage Reset

0 0 1 * *

Resetting API call counters or storage quotas on the first of each month. This is straightforward, but the gotcha is time zones -- if your users are global, you need to decide whether the reset happens at midnight UTC (simple but feels wrong to users in other zones) or at each user's local midnight (complex but fair).

Gotchas and Pitfalls to Avoid

Cron expressions are deceptively simple. Here are the mistakes that catch even experienced developers.

The Day-of-Month vs. Day-of-Week Trap

If you write 0 9 15 * 1 intending "9 AM on the 15th, but only if it's a Monday," you will be surprised. Standard cron treats this as "9 AM on the 15th of every month OR 9 AM on every Monday." The result is that your job runs every Monday and the 15th of every month -- far more often than you expected. To schedule "the 15th only when it falls on a Monday," you need application-level logic, not cron syntax alone.

Timezone Confusion

Your cron daemon uses the server's system timezone. If your server is UTC and you schedule 0 9 * * * thinking it will run at 9 AM Eastern, it will actually run at 4 AM or 5 AM Eastern depending on daylight saving time. Always document which timezone your cron jobs expect, and consider setting all servers to UTC to avoid ambiguity.

Daylight Saving Time Gaps and Overlaps

In the spring, when clocks jump forward from 2:00 AM to 3:00 AM, a job scheduled for 2:30 AM may not run at all. In the fall, when clocks fall back from 2:00 AM to 1:00 AM, a job scheduled for 1:30 AM may run twice. For critical jobs, avoid scheduling during the 1:00-3:00 AM window or use UTC.

Jobs That Outlast Their Interval

If you schedule a job every 5 minutes but the job itself takes 7 minutes, you will end up with overlapping executions. Most cron implementations do not prevent this. Use a lock file, a database flag, or a tool like flock to ensure only one instance runs at a time.

February 30th and Other Impossible Dates

Scheduling a job for 0 0 31 * * means it will only run in months that have 31 days -- January, March, May, July, August, October, and December. It will silently skip February, April, June, September, and November. If you need "last day of the month," cron cannot express this natively. You will need a daily job with application logic that checks whether today is the last day.

The "Every Second" Misconception

Standard 5-field cron has minute-level granularity. You cannot schedule something to run every 30 seconds using cron alone. Some extended formats (like those used in Spring Framework or Quartz) add a sixth field for seconds, but this is non-standard. If you need sub-minute scheduling, consider a different approach like a long-running process with an internal timer.

Testing Your Cron Expressions

Writing a cron expression and deploying it directly to production is a recipe for surprises. You should always validate your expressions before they go live.

Use a Visual Validator

A cron expression tool lets you paste in your expression and immediately see a plain-English description of what it does plus a list of upcoming execution times. This is the fastest way to catch mistakes. If the next-run list does not match your expectations, you can iterate quickly without waiting for the actual job to fire (or not fire).

Check Edge Cases Manually

After validating the expression itself, think through calendar edge cases. Will it behave correctly in February? During DST transitions? On New Year's Day? At the end of a month with 30 vs. 31 days? These scenarios are easy to overlook but cause real production issues.

Log Everything

When you deploy a cron job, make the first line of your script log a timestamp and the job name. This gives you an audit trail to verify that the job actually ran when you expected it to. Absence of evidence (no log entry) is evidence of absence (the job did not run).

Advanced Tips for Production Systems

Stagger Your Jobs

If you have 20 cron jobs that all run at 0 0 * * * (midnight), you are creating an artificial load spike. Spread them across the hour: run the first at 0 0, the second at 3 0, the third at 6 0, and so on. A few minutes of offset makes no functional difference but significantly reduces contention for CPU, memory, and database connections.

Add Random Jitter

In distributed systems where multiple servers share the same cron schedule, adding a random delay at the start of the script (e.g., sleep $((RANDOM % 60))) prevents thundering herd problems. This is especially important for jobs that hit external APIs with rate limits.

Use Descriptive Comments

In a crontab file, add a comment above each expression explaining what it does, who added it, and when. Six months from now, 0 3 * * 0 will be meaningless without context, but a comment saying "Weekly database backup -- added by ops team, Jan 2026" tells the whole story.

Calculate Business Days Separately

Cron cannot express "every business day excluding holidays." You can approximate it with * * * * 1-5 for weekdays, but holidays require application logic. Maintain a holiday calendar in your application and have the cron job check it before proceeding.

Monitor for Missed Runs

Set up alerting for when a critical cron job fails to run. Tools like Healthchecks.io follow a "dead man's switch" pattern: your cron job pings a URL when it runs successfully, and the monitoring service alerts you if the ping does not arrive within the expected window. This catches silent failures that logs alone might miss.

Document Your Schedules

Maintain a central registry of all cron jobs in your system, including the expression, the script or command it runs, expected duration, what happens if it fails, and who is responsible. As your system grows, this documentation becomes essential for onboarding new team members and troubleshooting incidents.