Cron syntax looks cryptic until you use it a few times, then it clicks and stays clicked. This cheat sheet is the reference we wish we'd had when we were staring at a blank cron field trying to remember which star meant "minute" and which meant "hour".
Every example below is a real-world pattern teams actually use. Copy-paste, tweak, and verify with the free cron job debugger before you ship.
The five-field structure
Standard cron expressions have five fields, separated by spaces:
┌───────── minute (0 - 59)
│ ┌─────── hour (0 - 23)
│ │ ┌───── day of month (1 - 31)
│ │ │ ┌─── month (1 - 12)
│ │ │ │ ┌─ day of week (0 - 6, where 0 or 7 = Sunday)
│ │ │ │ │
* * * * *
A * means "any value". The expression * * * * * means "every minute of every hour of every day".
Some tools (like Quartz-based schedulers) use six fields with seconds first. We'll cover that at the end. For Crontap, Linux crontab, Vercel Cron and most of the web, five fields is the norm.
The special characters
| Symbol | Meaning | Example |
|---|---|---|
* | Any value | * * * * * (every minute) |
, | List of values | 0,15,30,45 * * * * (at 0, 15, 30 and 45 past the hour) |
- | Range of values | 0 9-17 * * * (every hour from 09:00 to 17:00) |
/ | Step values | */5 * * * * (every 5 minutes) |
? | No specific value (some schedulers) | 0 12 ? * MON, noon on Monday (Quartz-style) |
L | Last (some schedulers) | 0 12 L * *, noon on the last day of the month |
? and L are not standard cron. They're extensions used by Quartz, AWS EventBridge and a few others. Crontap, crontab, and most web-cron services don't support them. Stick to *, ,, - and / for maximum portability.
Minute-level patterns
These are the go-to patterns for frequent jobs: polling, syncing, cache warming, health checks.
| Expression | Runs | Typical use |
|---|---|---|
* * * * * | Every minute | Health checks, dev testing |
*/2 * * * * | Every 2 minutes | Quick polling loop |
*/5 * * * * | Every 5 minutes | Data sync, cache warming |
*/10 * * * * | Every 10 minutes | Light polling |
*/15 * * * * | Every 15 minutes | Periodic status checks |
*/30 * * * * | Every 30 minutes | Medium-frequency syncs |
0,30 * * * * | At 0 and 30 past every hour | Twice-hourly, on-the-dot |
15 * * * * | 15 minutes past every hour | Offset from the top of the hour |
Heads up: */5 on the minute field means "every 5 minutes starting from minute 0", so 00, 05, 10, 15… not "5 minutes from now". Cron is wall-clock relative, not relative to when you create the schedule.
Hourly patterns
| Expression | Runs | Typical use |
|---|---|---|
0 * * * * | Every hour on the hour | Cache refresh, hourly digests |
0 */2 * * * | Every 2 hours on the hour | Moderate-frequency tasks |
0 */3 * * * | Every 3 hours | Periodic summaries |
0 */4 * * * | Every 4 hours | 6 runs per day |
0 */6 * * * | Every 6 hours | 4 runs per day |
0 */12 * * * | Every 12 hours | Twice-daily heartbeat |
30 * * * * | Half-past every hour | Offset hourly job |
Quick preference note: I'd pick 0 */4 * * * over 0 0,4,8,12,16,20 * * * for readability. They fire at exactly the same times, but the step form is easier to scan.
Daily patterns
| Expression | Runs | Typical use |
|---|---|---|
0 0 * * * | Midnight every day | Nightly backup, batch jobs |
0 6 * * * | 06:00 every day | Before business hours |
0 9 * * * | 09:00 every day | Start-of-day dashboard |
30 9 * * * | 09:30 every day | Daily standup reminder |
0 18 * * * | 18:00 every day | End-of-day report |
0 0,12 * * * | Midnight and noon | Twice daily |
Important: the time here is in the schedule's timezone. If your server runs UTC and you're in New York, 0 9 * * * fires at 09:00 UTC (04:00 or 05:00 EST, depending on DST). Crontap lets you set timezone per schedule, which sidesteps this entirely.
Business hours
These are patterns teams use to stay quiet outside working hours.
| Expression | Runs |
|---|---|
0 9-17 * * 1-5 | Every hour on the hour, 09:00–17:00, Mon–Fri |
*/15 9-17 * * 1-5 | Every 15 minutes during business hours, Mon–Fri |
0 9,13 * * 1-5 | 09:00 and 13:00, Mon–Fri |
30 9 * * 1-5 | 09:30 weekdays |
0 17 * * 5 | 17:00 every Friday |
The 1-5 in the day-of-week field means Monday through Friday. 6,0 (or 6,7) means Saturday and Sunday, a.k.a. weekends. Day 0 and day 7 both mean Sunday; the spec allows either.
Weekly patterns
| Expression | Runs | Typical use |
|---|---|---|
0 9 * * 1 | 09:00 every Monday | Weekly kickoff |
0 17 * * 5 | 17:00 every Friday | Weekly wrap-up |
0 8 * * 1-5 | 08:00 on weekdays | Morning digest |
0 10 * * 6,0 | 10:00 on weekends | Weekend-only task |
0 0 * * 0 | Sunday midnight | Start-of-week reset |
0 12 * * 1,3,5 | Noon on Mon/Wed/Fri | Three-times-a-week task |
You can use the short names (MON, TUE, WED, THU, FRI, SAT, SUN) instead of numbers on most crons, but numeric is more portable. Crontap accepts both.
Monthly patterns
| Expression | Runs | Typical use |
|---|---|---|
0 0 1 * * | Midnight on the 1st | Monthly billing run |
0 0 15 * * | Midnight on the 15th | Mid-month reset |
0 9 1 * * | 09:00 on the 1st | Monthly report email |
0 0 1 */3 * | Midnight on the 1st, every 3 months | Quarterly job |
0 0 1 1 * | Jan 1st at midnight | Annual reset |
The "last day of the month" is tricky in standard cron. There's no standard way to express it in 5 fields. Options:
- Run on the 28th and bail on days that aren't the last (in your code).
- Use
0 0 28-31 * *, which fires every day from the 28th to the 31st, and your code checks which is the last and acts accordingly. - Switch to a scheduler that supports
L(Quartz-based, AWS EventBridge, some Java schedulers).
Common real-world patterns
These are the expressions we see people reach for most often. Steal them.
| What you want | Expression |
|---|---|
| Health check every minute | * * * * * |
| Poll an external API every 5 minutes | */5 * * * * |
| Sync data every 15 minutes during business hours (weekdays) | */15 9-17 * * 1-5 |
| Warm the cache every 2 hours | 0 */2 * * * |
| Nightly backup at 02:00 | 0 2 * * * |
| Send the daily digest at 08:30 weekdays | 30 8 * * 1-5 |
| Post the weekly report Monday at 09:00 | 0 9 * * 1 |
| Run monthly invoices on the 1st at midnight | 0 0 1 * * |
| Warm the homepage on weekends only | 0 */3 * * 6,0 |
| Quarterly reset on Jan/Apr/Jul/Oct 1st at midnight | 0 0 1 */3 * |
Getting timezones right
Cron expressions don't include a timezone. They just mean "this pattern, in whatever timezone the scheduler is running", which is a common source of confusion.
- Linux
crontabuses the system timezone. - AWS EventBridge defaults to UTC.
- GitHub Actions cron is always UTC.
- Vercel Cron is always UTC.
- Crontap lets you pick a timezone per schedule.
If you need a job at "09:00 local time" for users in multiple timezones, the cleanest approach is to create one schedule per timezone, each with the same cron and the right timezone setting. That's what Crontap is designed for.
Five-field vs six-field cron (seconds)
Some systems add a seconds field at the start, giving you six fields. These are the common ones:
- Quartz (Java schedulers, Spring): 6 or 7 fields.
- AWS EventBridge: 6 fields, with the year as an optional 7th.
- Cron4J, node-cron: depends on config.
Six-field example:
*/30 * * * * * # every 30 seconds (Quartz-style)
Most web-cron services stick to five fields and don't go below one-minute granularity (Crontap included). If you actually need sub-minute precision, you likely want a pub/sub or message queue, not cron.
Debugging cron expressions
The fastest way to verify a cron expression is to plug it into a debugger that shows the next N runs. We built a free one: tool.crontap.com/cronjob-debugger.
Paste an expression, pick a timezone, and you get a plain-English translation plus the next upcoming runs. If something doesn't match what you expect, you'll see it in the preview before a real job misses (or over-fires).
For comparing multiple expressions side by side, there's also a multiple-cronjobs version.
Gotchas we've hit the hard way
- Day-of-week 0 or 7 both mean Sunday. Don't mix them in the same expression; pick one.
- Day-of-month and day-of-week both set = OR, not AND.
0 0 1 * 1means "midnight on the 1st or any Monday" in most classic cron implementations. Double-check your scheduler's behavior. @reboot,@daily,@hourlyetc. are Linux crontab conveniences. They don't work in most web-cron services.- Leap seconds and DST. Most schedulers handle DST sensibly (by firing once on the spring-forward and skipping the fall-back, or vice versa). If you have a DST-critical job, test it.
- "Every minute" under heavy load. If your job sometimes takes 90 seconds, runs can overlap. Most mature schedulers (Crontap included) don't stack runs: the next fires after the previous finishes or is marked late. Check your scheduler's docs.
When cron isn't the answer
A few cases where cron is the wrong tool:
- Sub-minute precision. Use a queue or a long-running loop.
- Event-driven work. Use a webhook or a pub/sub trigger.
- Complex workflows with dependencies. Use a workflow engine (Airflow, Temporal, Inngest, Trigger.dev).
- Durable retries with exponential backoff. A real queue does this better than any cron.
For everything else (periodic polling, nightly batch, weekly reports, hourly health checks, recurring webhooks), cron is still the right answer after 50 years.
Running these schedules
If you already have a place to run cron, paste any of these expressions in and you're done. If you don't (or if you want proper logs, retries, failure notifications and per-schedule timezones), Crontap handles all of the above. Free plan gets you 1 schedule and hourly intervals, paid starts at $3.25/month for unlimited.
If you want guided setups instead of manual cron, we have walkthroughs for Zapier, n8n, Make.com and IFTTT. For specific patterns like recurring reports or scheduled notifications, the use cases index has a page for each.
Whatever you run them on, verify your expressions in the free cron debugger first. It's saved me from more "why didn't that fire?" debugging sessions than anything else on this list.