Cron: Every 10 Minutes
*/10 * * * * runs six times an hour — at :00, :10, :20, :30, :40, and :50. It's a common choice for jobs that need to be timely without the overhead of 5-minute or minute-level polling, like periodic report generation or moderate-frequency data syncs.
*/10 * * * *
Examples & Variations
Common Mistakes
- Assuming */10 evenly divides every hour into exactly 6 slices measured from job start — it's anchored to :00, not to when the cron entry was added.
- Stacking multiple */10 jobs at the same offset, causing them to compete for the same resources every 10 minutes instead of spreading load.
- Using 10-minute polling for something time-sensitive that really needs */5 or */1 — check your actual latency requirement before defaulting to this interval.
Best Practices
- Offset competing jobs with different step ranges (e.g. 2-58/10 for one job, 5-55/10 for another) so they don't all hit the database in the same second.
- 10 minutes is a reasonable interval for external API polling that has rate limits — it keeps you well under most per-minute quotas.
- Log skipped runs explicitly if you add overlap protection, so a silently-skipped job doesn't look like a missing cron entry during debugging.
Frequently Asked Questions
- What's the difference between */10 and 0,10,20,30,40,50?
- None functionally — */10 is shorthand that expands to exactly that comma-separated list. Use whichever is more readable to you; cron parses them identically.
- Can I run every 10 minutes but skip the first hour of the day?
- Yes — combine a step with an hour range: */10 1-23 * * * runs every 10 minutes from 1 AM to 11:50 PM, skipping the midnight hour entirely.
- Is 10 minutes a good default for cache invalidation?
- It's a reasonable middle ground for content that changes occasionally — for anything more time-sensitive, consider event-driven invalidation instead of polling on any fixed interval.