Running a cron job every 10 minutes is a great balance between freshness and efficiency. The expression is simple, but there are a few scheduling details that every operator should know before deploying it.
The expression for every 10 minutes
Use this cron line for an every-10-minute schedule:
*/10 * * * *
That means: every 10th minute of every hour, every day, every month, and every day of the week. It runs at 0, 10, 20, 30, 40 and 50 minutes past the hour.
Common variants
- */10 * * * * — every 10 minutes, all day.
- 5-55/10 * * * * — every 10 minutes starting at 5 past the hour.
- */10 9-17 * * 1-5 — every 10 minutes during business hours on weekdays.
Why choose every 10 minutes
Every 10 minutes is often enough for monitoring, lightweight ETL jobs, data syncs, and cache refreshes. It uses less system overhead than every 5 minutes while still keeping results fresh for most use cases.
How it differs from every 5 minutes
*/5 * * * * runs six times per hour; */10 * * * * runs three times per hour. If your task is not time-critical or if you want to reduce load, the 10-minute interval is usually the better choice.
Avoid these cron mistakes
Do not use a six-field expression in a standard crontab. Standard cron expects exactly five fields: minute, hour, day of month, month, and day of week.
Remember that day-of-week and day-of-month are ORed in classic cron. If you restrict both fields, the job runs when either condition matches.
Verify with the generator
Paste */10 * * * * into the Cron Expression Generator to see a plain-English interpretation and the next few run times in your local timezone.
FAQ
Does */10 * * * * run at 10 and 20 past the hour? Yes — the step value means every 10th minute, so it runs at 0, 10, 20, 30, 40 and 50.
Can I start at 5 minutes past the hour? Yes — use 5-55/10 * * * * to run at 5, 15, 25, 35, 45 and 55 minutes past each hour.
Will this expression run in all cron systems? Standard Unix-style cron does. Some schedulers support seconds or nonstandard syntax; if your tool expects six fields, do not use this line.
Make a 10-minute job safe to re-run
The moment a scheduler can overlap itself (a slow run still executing when the next fires), everything downstream feels it: duplicate emails, double counts, conflicting writes. Make the job idempotent — insert-or-update instead of blind insert, tag records with the run timestamp — and record when a run starts. With that guard plus idempotent writes, even a manual re-run for backfill is safe.
What to watch in the logs
- Runtime creeping toward 10 minutes — the real fix is a faster job or a longer cadence.
- Missed windows after a long pause, which often means the daemon restarted late.
- Errors only on the :00 run, a classic sign the job depends on the previous hour finishing.
