Master cron expressions with this in-depth guide. Learn cron syntax, common scheduling patterns, timezone handling, special strings, testing strategies, and platform differences for Linux, AWS, Kubernetes, and more.
Those five asterisks looked like some ancient incantation that could either run my backup script perfectly or delete everything at 3 AM. After one particularly memorable incident at Šikulovi s.r.o. where a misconfigured cron job sent 50,000 emails in an hour, I decided to actually learn how these things work. Spoiler: they're not that complicated once you get the pattern down.
The word 'cron' comes from the Greek 'chronos' meaning time, which is about as poetic as Unix gets. The cron daemon sits there patiently reading your crontab files and firing off commands when the time comes. It's been doing this since the 1970s and honestly, the syntax hasn't changed much. That's either reassuring or terrifying depending on how you look at it.
Here's the mental model that finally made cron click for me: read it left to right like a sentence about time, starting with the smallest unit. Minute, hour, day of month, month, day of week. That's it. 30 9 * * 1 literally reads as 'minute 30, hour 9, any day, any month, Monday.'
You only need to master four characters for 90% of scheduling tasks. The asterisk means 'any', the comma separates multiple values, the hyphen creates ranges, and the slash creates steps. Everything else is platform-specific extras.
I probably write the same 10 cron expressions over and over. Here are the ones that cover most real-world scenarios. I used to have these on a sticky note on my monitor before I built the Cron Generator tool.
I went years without knowing about these. Most cron implementations support readable shortcuts that save you from counting asterisks. They're not universal though, so I always test before relying on them in production.
I've been burned by timezones so many times that I now put a comment above every single cron entry stating what timezone I think it's running in. DST transitions are particularly nasty - your 2:30 AM job might not exist or might run twice depending on the direction of the change.
Every cron mistake I've made could have been caught by testing. I once deployed a job that was supposed to run daily but ran every minute because I had the fields in the wrong order. 1,440 executions before I noticed. Now I always preview the next few run times in the Cron Generator before pushing anything to production.
If you're on a Linux server, crontab is probably what you're using. It's the OG, the one everything else is based on. A few things caught me off guard when I started: the environment is basically empty, output goes to email by default, and there's no built-in logging.
AWS decided cron needed a sixth field (year) and a question mark placeholder. It's just different enough to break your muscle memory. I've wasted hours debugging why my expression works locally but not in AWS.
Kubernetes uses standard 5-field cron but adds its own complexity. concurrencyPolicy is the setting I always forget to configure - by default it allows overlapping runs, which can be disastrous for long-running jobs.
GitHub throttles anything more frequent than every 5 minutes, and scheduled workflows can be significantly delayed during busy periods. I've seen 10+ minute delays on free tier. Also, they disable your scheduled workflows after 60 days of repo inactivity. Found that out the hard way.
Silent failures are the worst. The job doesn't run, nothing is logged, you have no idea why. Here's my debugging checklist, roughly in order of likelihood:
This one bit me hard. If you specify both day-of-month AND day-of-week (not asterisks), standard cron uses OR logic. So 0 9 15 * 1 means '9 AM on the 15th OR any Monday' not '9 AM on the 15th if it's a Monday.' Almost nobody wants OR logic. I always use * for one of them now.
After reviewing countless crontabs at Šikulovi s.r.o. and in clients' systems, these are the patterns that cause problems over and over:
After years of learning the hard way, here's my standard checklist for any production cron job. It takes 10 extra minutes upfront but saves hours of debugging later.
Cron is great for simple scheduling, but sometimes you need more. Job dependencies, retries, distributed execution, observability - if you need any of these, consider alternatives. I use cron for simple stuff and reach for other tools when complexity grows.
Cron is deceptively simple. Five fields, a few special characters, and you can schedule almost anything. The hard part isn't the syntax - it's all the surrounding concerns: timezones, logging, locking, alerting, testing. Get those right and cron just works. Get them wrong and you'll be debugging at 3 AM like I did.
I built the Cron Generator tool because I was tired of making preventable mistakes. Use it to build your expressions, preview the next run times, and copy them with confidence. Your future self will thank you.
The expression * * * * * means "every minute of every hour of every day of every month on every day of the week"—in other words, the job runs every single minute. Each asterisk means "any value" for that field. This is typically used only for testing or very high-frequency monitoring tasks.
Use */5 * * * * to run every 5 minutes. The */5 in the minute field means "every 5th minute" (0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55). You can use */n in any field to create step intervals.
Common causes include: the cron service not running, incorrect file permissions, missing execute permission on scripts, commands not using absolute paths, environment variables not available in cron environment, timezone differences, or syntax errors in the expression. Check cron logs and test commands manually.
Both 0 and 7 represent Sunday in the day-of-week field. This exists for compatibility with different cron implementations. Most systems accept both values, but 0 is more commonly used. When using names (SUN, MON, etc.), there is no ambiguity.
Standard cron does not support "last day of month" directly since months have different lengths. Some implementations support L (e.g., 0 0 L * *). Alternatively, use a script that checks if tomorrow is the 1st, or schedule for days 28-31 and have the script verify the date.
It depends on the platform. Linux cron uses the system timezone. AWS EventBridge and GitHub Actions always use UTC. Kubernetes CronJobs use the controller timezone by default but support explicit timezone configuration. Always check your platform documentation and document the expected timezone.
Not directly with a single expression, since 90 does not divide evenly into 60 minutes or 24 hours. You would need multiple cron entries (e.g., jobs at 0:00, 1:30, 3:00, 4:30, etc.) or use a different scheduling approach like a daemon that sleeps between runs.
By default, cron will start another instance of the job at the next scheduled time, even if the previous run is still executing. This can cause resource exhaustion and data corruption. Use file-based locking (flock), PID files, or your scheduler's concurrency controls to prevent overlapping runs.
Founder of CodeUtil. Web developer building tools I actually use. When I'm not coding, I experiment with productivity techniques (with mixed success).
Ready-to-use cron expressions for every common task: every minute, hourly, daily at midnight, weekly, monthly, weekdays only, and more. Includes Unix crontab, AWS EventBridge, GitHub Actions, and Kubernetes CronJob formats.
Cron expressions have caused me more 3 AM incidents than I care to admit. Here is my guide to validating them properly, plus every mistake I have made so you do not have to.
I used to push broken code constantly. Now my git hooks catch linting errors, run tests, and validate commits before they embarrass me. Here's my exact setup.