Cron Expressions Explained: Schedule Recurring Tasks Without the Headaches

Cron is the scheduling system that runs behind the scenes on nearly every Linux and macOS system. It executes commands at specified times, whether that is running a backup every night at 2 AM, clearing temp files every Sunday, or sending a report on the first of each month.

The problem with cron is the expression syntax. A cron expression like 0 2 1-5 is perfectly logical once you understand it, but it is not something most people can read at a glance. The five fields (minute, hour, day of month, month, day of week) pack a lot of meaning into a short string, and mixing up the order or misusing a wildcard can schedule your task at the wrong time or, worse, every minute.

The Cron Expression Builder lets you build cron expressions visually. Select the schedule you want from dropdowns and toggles, and it generates the cron expression with a human-readable description. You can also paste an existing expression to see what it means.

The Five Fields of a Cron Expression

A standard cron expression has five fields separated by spaces:

` * | | | | | | | | | +--- Day of week (0-7, where 0 and 7 are Sunday) | | | +----- Month (1-12) | | +------- Day of month (1-31) | +--------- Hour (0-23) +----------- Minute (0-59) `

Each field accepts: - A specific value: 5 means the 5th minute, the 5th hour, etc. - A wildcard * meaning "every" value - A range: 1-5 means Monday through Friday (in the day-of-week field) - A list: 1,15 means the 1st and 15th - An interval: */5 means every 5 units (every 5 minutes, every 5 hours, etc.)

Some examples to build intuition:

0 9 * - At 9:00 AM every day 30 14 1-5 - At 2:30 PM, Monday through Friday 0 0 1 - At midnight on the first of every month /15 * - Every 15 minutes 0 6 0 - At 6:00 AM every Sunday

The trickiest part is remembering the field order. Minute first, not hour. Day of month before month. Day of week at the end. The builder tool removes this memorization problem entirely.

Common Scheduling Patterns

Here are the cron expressions for the most frequently needed schedules:

Every day at a specific time: - 0 8 * - Daily at 8 AM - 0 0 * - Daily at midnight - 0 18 * - Daily at 6 PM

Business hours only: - 0 9 1-5 - Weekdays at 9 AM - 0 9-17 1-5 - Every hour from 9 AM to 5 PM, weekdays - /30 9-17 * 1-5 - Every 30 minutes during business hours

Weekly: - 0 10 1 - Every Monday at 10 AM - 0 9 5 - Every Friday at 9 AM - 0 0 0 - Every Sunday at midnight

Monthly: - 0 0 1 - First day of every month at midnight - 0 9 15 - 15th of every month at 9 AM - 0 0 1 1,4,7,10 * - First day of every quarter at midnight

Periodic intervals: - /5 * - Every 5 minutes (careful with this one in production) - 0 /2 - Every 2 hours - 0 /6 - Every 6 hours (4 times per day)

The Date Calculator is helpful when you need to figure out what day of the week a specific date falls on, or calculate intervals between dates for setting up schedules.

Cron in Different Environments

The basic 5-field cron syntax is nearly universal, but different platforms add their own extensions.

Linux/macOS crontab uses the standard 5-field format. Edit with crontab -e. Each line is one scheduled task: the cron expression followed by the command to run.

` 0 2 * /home/user/scripts/backup.sh `

GitHub Actions uses cron expressions in workflow files for schedule triggers. Same 5-field format, but runs in UTC and has a minimum interval of 5 minutes.

`yaml on: schedule: - cron: '0 9 1-5' `

AWS CloudWatch / EventBridge uses a 6-field format that adds a year field and uses ? instead of * for day-of-month or day-of-week when the other is specified. The syntax differences trip people up regularly.

Kubernetes CronJobs use the standard 5-field format. They schedule pods to run at specified times.

Vercel Cron uses standard 5-field expressions configured in vercel.json. Supports up to 2 cron jobs on the free plan.

Node.js libraries like node-cron and cron support the standard 5-field format, and some add a 6th field for seconds at the beginning.

The Cron Expression Builder generates standard 5-field expressions that work across all these platforms. If your platform uses a 6-field format, you typically just add 0 as the seconds field at the beginning.

Debugging Cron Jobs That Do Not Run

Cron jobs fail silently more often than you would expect. Here are the most common reasons and how to fix them:

Wrong timezone. Cron runs in the server's timezone by default. If your server is in UTC and you scheduled a job for 9 AM expecting your local time, it will run at the wrong time. Check the timezone with date and adjust accordingly.

Path issues. Your cron job runs in a minimal environment without your normal shell profile. Commands that work in your terminal may fail in cron because the PATH is different. Use absolute paths for everything: /usr/local/bin/python3 instead of python3.

Permission problems. The cron daemon runs your job as your user, but environment variables and file permissions might differ from your interactive session. If a script needs to read a file or write to a directory, verify the permissions explicitly.

Output goes nowhere. By default, cron sends output to the user's system mailbox, which most people never check. Redirect output to a log file to see what happened:

` 0 2 * /path/to/script.sh >> /var/log/myjob.log 2>&1 `

The job ran but did nothing. Your script might depend on environment variables that are set in your .bashrc or .zshrc but not available in the cron environment. Either source those files in your cron script or set the variables explicitly.

When debugging timing issues, the Unix Timestamp converter helps verify that timestamps in your logs correspond to the expected execution times.

Cron Alternatives for Modern Applications

Traditional cron works well for server-based scheduling, but modern applications often need something different.

Serverless functions with scheduled triggers. If your app runs on Vercel, Netlify, or AWS Lambda, you can schedule function executions using their built-in cron support. No server to maintain, and the function only runs (and costs money) when triggered.

Message queues with delayed delivery. For tasks that need to run at a specific time in the future ("send a reminder email in 3 days"), message queues like SQS or BullMQ are better than cron. They handle the timing and retry logic, and the "schedule" is per-message rather than recurring.

Workflow orchestrators. Tools like Temporal, Airflow, or n8n handle complex multi-step workflows with dependencies, retries, and error handling that cron cannot provide. If your scheduled task is actually a pipeline with multiple steps, these tools are worth the setup effort.

Database-driven scheduling. Store scheduled events in your database with a "run_at" timestamp. A simple worker process polls the database every minute and executes due tasks. This gives you visibility into scheduled tasks through your normal application tooling and makes it easy to cancel or reschedule individual executions.

For simple recurring tasks, cron remains the fastest tool to set up. If you need visibility, retries, or complex workflows, consider the alternatives.

FAQ

What happens if a cron job takes longer than the interval?

Cron does not care. If you have a job scheduled every 5 minutes and it takes 7 minutes to complete, the next instance starts at the 5-minute mark while the previous one is still running. This can cause resource conflicts and data corruption. Protect against this by using a lock file or a process check at the start of your script.

Can I schedule a cron job for the last day of every month?

There is no direct cron syntax for "last day of the month" because months have different lengths. A common workaround: ` 0 0 28-31 [ $(date -d tomorrow +\%d) -eq 1 ] && /path/to/script.sh ` This runs on days 28-31 but only executes the script if tomorrow is the 1st, meaning today is the last day of the month.

Is `*/1` the same as `*`?

Yes. /1 means "every 1 unit" which is identical to "every unit" (). Both mean every minute, every hour, etc. depending on the field. Use * for clarity.

How do I run a cron job only once?

Cron is for recurring schedules. For a one-time execution, use the at command on Linux/macOS: echo '/path/to/script.sh' | at 14:30 tomorrow. Or simply use setTimeout in your application code.

What is the minimum interval for cron?

Standard cron supports minute-level granularity. The shortest interval is every minute: *. If you need sub-minute scheduling (every 10 seconds), cron is not the right tool. Use a systemd timer, a dedicated scheduler, or a loop in your application.