Every 10 Minutes Cron Expression
Runs six times per hour: minutes 0, 10, 20, 30, 40, 50.
*/10 * * * * in POSIX cron
Expression
*/10 * * * *Try it in the tester →Field Breakdown
How It Works
Step value `*/10` matches every minute that is divisible by 10, so the job runs six times per hour.
Example Run Times
- 12:00:00
- 12:10:00
- 12:20:00
- 12:30:00
- 12:40:00
Frequently Asked Questions
How many times does this run per day?
144 times — 6 runs per hour × 24 hours.
*/10 * * * * in Quartz / Spring
This trigger lands six times an hour, at minutes :00, :10, :20, :30, :40, and :50 — 144 executions a day. In the Quartz grammar the step lives in the minute field, with seconds pinned to 0 up front.
Quartz / Spring expression
0 */10 * * * ?Try it in the tester →At second 0, every 10 minutes, every hour
Unix / POSIX equivalent: */10 * * * *
Field Breakdown
Using It with Quartz / Spring
Ten minutes is a popular middle ground for Spring Boot batch tickers: frequent enough for sync jobs against a partner API, sparse enough that OAuth token refreshes and report rollups don't hammer downstream systems. Drop the string into @Scheduled(cron = "0 */10 * * * ?"), or in Quartz proper attach it via CronScheduleBuilder.cronSchedule() when building the trigger, optionally chaining .withMisfireHandlingInstructionDoNothing() if missed runs should simply be skipped.
Quartz-Specific Notes
- →*/10 in the minute field expands to exactly 0,10,20,30,40,50 — the step always anchors at the field minimum, never at deployment time.
- →Both day fields can't be *: Quartz insists one of them is ?, which is why the sixth field here is ? rather than the * a crontab would use.
- →CronExpression.getNextValidTimeAfter(new Date()) is the quickest way to sanity-check that your next firing is the :10 boundary you expect.
Frequently Asked Questions
How is this different from fixedDelay = 600000 in Spring?
fixedDelay measures 10 minutes from the end of each execution, so the schedule drifts with job duration. The cron form is calendar-anchored: it fires on the :00/:10/:20 boundaries no matter how long the previous run took.
Can I run every 10 minutes but only during business hours?
Yes — constrain the hour field: 0 */10 9-17 * * ? fires every 10 minutes from 09:00 through 17:50, then goes quiet overnight.
*/10 * * * * in AWS EventBridge
Six runs an hour, 144 a day: the */10 step in the minute field triggers whenever the UTC minute is divisible by 10. It is a comfortable middle ground when 5 minutes is wasteful but 15 leaves data too stale.
AWS EventBridge expression
cron(*/10 * * * ? *)Try it in the tester →Every 10 minutes UTC
Unix / POSIX equivalent: */10 * * * *
Field Breakdown
Using It with AWS EventBridge
Wire it up as the ScheduleExpression of an EventBridge rule and point the rule at up to five targets — a common pairing is one Lambda that refreshes a cache plus an SQS queue that fans the same tick out to workers. Ten-minute cadences show up in log shippers, CloudWatch metric aggregators that pre-compute dashboards, and health probes against partner endpoints whose SLAs are measured in tens of minutes.
AWS-Specific Notes
- →Fire minutes are :00, :10, :20, :30, :40, and :50 of every hour, evaluated in UTC for classic rules.
- →A single rule supports a maximum of five targets, so this one schedule can drive several ten-minute jobs at once.
- →Step values divide from the field minimum, so */10 in minutes happens to match clean clock boundaries — unlike, say, */7, which would produce uneven gaps at the top of each hour.
Frequently Asked Questions
Does cron(*/10 * * * ? *) behave differently from rate(10 minutes)?
Yes, subtly. The cron form snaps to :00/:10/:20 clock boundaries; rate(10 minutes) counts from when the schedule was created or enabled, so its runs drift off the round numbers.
Can I make the ten-minute tick run only during business hours?
That is exactly why you would keep the cron form: change the hour field, for example cron(*/10 13-21 ? * 2-6 *) for roughly 9-to-5 US Eastern in UTC. rate() cannot express that.
*/10 * * * * in GitHub Actions
Six runs per hour, 144 per day: */10 in the minute field fires whenever the UTC clock minute is divisible by 10. It sits one comfortable notch above the platform's 5-minute floor, which makes it a popular compromise between freshness and queue contention.
GitHub Actions expression
*/10 * * * *Try it in the tester →Every 10 minutes UTC
Unix / POSIX equivalent: */10 * * * *
Field Breakdown
Using It with GitHub Actions
Drop the quoted string into on: schedule: - cron: "*/10 * * * *" in a file under .github/workflows. Ten-minute cadence suits status-page updaters, issue-triage bots that label new activity, and lightweight scrapers feeding a dashboard. A common refinement is shifting to an offset form like 7-57/10 or an explicit list like 4,14,24,34,44,54 so the workflow avoids the :00 and :10 boundary slots that the rest of the platform piles onto, trading a tidy schedule for noticeably faster pickup.
GitHub-Specific Notes
- →Fire times align to wall-clock minutes :00, :10, :20, :30, :40, :50 UTC — not to ten minutes after the workflow was last run.
- →Runs aligned to round minutes share queue slots with thousands of other repositories; offsetting the minute field (for example 4,14,24,34,44,54) measurably reduces start delay.
- →On a public repository, 60 days without any repository activity automatically disables this schedule; a maintainer must re-enable it from the Actions tab.
Frequently Asked Questions
Why does my 10-minute workflow start at :13 instead of :10?
GitHub's scheduler is best-effort and round-number slots are congested. A few minutes of drift is normal; if exact timing matters, Actions schedules are the wrong tool.
Can I make the 10-minute interval start from a different minute?
Yes — use an explicit list like 2,12,22,32,42,52 * * * * or the range-step form 2-52/10. Both are valid 5-field syntax and keep the same six-runs-per-hour rhythm while dodging the busiest slots.