25 Ready-to-Use Cron Expressions for Common Schedules

25 ready-to-use schedules organized by frequency. Copy the one you need.

Each expression uses the standard five-field format: minute, hour, day-of-month, month, day-of-week. If you need a refresher on operators like *, /, and ,, see the cron syntax cheat sheet.

Every minute / second-level intervals

Need sub-minute scheduling? Standard cron tops out at one-minute granularity — there’s no way to express “every 30 seconds” in a cron expression. If you need second-level intervals, use a loop with a sleep inside a once-per-minute cron job, or use a scheduler that supports sub-minute intervals natively.

Hourly schedules

Daily schedules

Weekly schedules

Monthly and beyond

Real-world application schedules

Here are cron expressions paired with specific use cases — copy these directly into your scheduler:

Edge cases and gotchas

Day-of-month vs day-of-week conflict

When both day-of-month and day-of-week are set, most cron daemon implementations run the job when either condition is met, not both. This is a genuine gotcha that’s been confusing developers for decades — the cron man page buries it, and nothing warns you when you write the expression:

# You might think: "1st of the month, but only if it's a Monday"
# Actually means: "Every 1st of the month AND every Monday"
0 9 1 * 1

To run only on the 1st Monday of the month, handle the logic in your application code and schedule the job to run every Monday:

# Run every Monday at 9 AM, check the date in your handler
0 9 * * 1

February and the 29th–31st

0 0 31 * * runs only in months with 31 days — it silently skips February, April, June, September, and November. If you want “last day of the month,” there’s no native cron expression for it. Use 0 0 28-31 * * and check the date in your handler.

Overlapping executions

If a job takes 10 minutes and runs every 5 minutes, you’ll have overlapping executions. Two instances of your sync job writing to the same records simultaneously. Two billing runs processing the same invoices, charging customers twice. The job succeeds from cron’s perspective — it ran, it exited 0. The data is the thing that’s wrong, and it’s often subtly wrong in ways that take hours to spot.

The tricky part: this only happens under load. In development your jobs finish in 2 seconds. In production, with a real dataset, they take 12 minutes. And suddenly your 5-minute interval is a problem.

Solutions:

• Use a lock file or database lock to prevent concurrent runs
• Set a timeout shorter than the interval
• Use a scheduler that supports concurrency control

*/N doesn’t mean “every N from the last run”

*/10 * * * * means “every minute divisible by 10” (0, 10, 20, 30, 40, 50) — not “10 minutes after the last execution.” If your job runs at :10 and takes 12 minutes, the :20 trigger still fires on schedule. Cron is clock-based, not interval-based.

Tips for writing cron expressions

1. Always specify the minute field. Using * * * * * with a specific hour still fires every minute of that hour — not once.
2. Use UTC. Store and schedule in UTC to avoid daylight saving surprises. Convert to local time in your application layer.
3. Test before deploying. Paste your expression into a cron explainer tool to verify the next few run times.
4. Keep it simple. If your expression is getting complex, consider splitting it into two simpler schedules.
5. Document the intent. 0 9 * * 1 is meaningless without context — add a label like “Weekly Monday standup reminder” alongside it.

Use with Recuro

Every expression above works directly with Recuro’s cron scheduler. Paste the expression, point it at any HTTP endpoint — Recuro handles execution, retries, and alerting.