Cron expression for every 10 minutes

Field breakdown

Next runs

How this schedule works

Cron evaluates the five fields of */10 * * * * — minute, hour, day of month, month, day of week — against the clock once a minute and starts the job on any minute where all five match, which cronstrue reads as "Every 10 minutes": 144 runs per day. Within every hour it fires at :00, :10, :20, :30, :40, :50. Sixty divides by 10 without a remainder, so the gap between runs stays constant as the hour rolls over.

When to use every 10 minutes

Ten minutes halves the invocation count of a five-minute job while keeping data fresh enough for dashboards, webhook retries, and system-to-system syncs where nobody is watching the clock second by second. It is the interval to pick when a five-minute poll is being throttled upstream, or is costing more than the extra freshness is worth. Because the step always includes minute 0, jobs on this cadence pile up at the top of the hour alongside everything else on the host; an explicit offset list is worth the extra characters on busy infrastructure.

Common mistakes with every 10 minutes

The trap here is the top of the hour. Because the step is anchored at 0, this schedule fires at :00 alongside every hourly, two-hourly and daily job on the same host — a thundering herd that turns a ten-second job into a two-minute one at exactly the moment the machine is busiest. The fix is not a smaller interval, it is an offset: 5,15,25,35,45,55 keeps the cadence and dodges the crowd. The other slip is writing 10 * * * * by mistake, which drops the job from 144 runs a day to 24, at ten past each hour.

Platform snippets

The same expression, ready to paste into the four schedulers that read five-field cron. The notes below each snippet are the ones that follow from this schedule; the cron expression generator lists every caveat for every platform.

name: Scheduled workflow
on:
  schedule:
    - cron: '*/10 * * * *'
  workflow_dispatch:

jobs:
  scheduled:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run job
        run: echo "Running scheduled job"

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cron-job
spec:
  schedule: "*/10 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job
              image: my-image:latest
              command: ["/bin/sh", "-c", "echo Running"]
          restartPolicy: OnFailure

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [
    {
      "path": "/api/cron",
      "schedule": "*/10 * * * *"
    }
  ]
}

# Edit your crontab: crontab -e
*/10 * * * * /path/to/command

# With logging:
*/10 * * * * /path/to/command >> /var/log/cron.log 2>&1

Variations

• */5 * * * * Every 5 minutes Twice the frequency, at the practical floor for hosted schedulers. Take it when ten minutes of staleness turns out to be visible to someone.
• */15 * * * * Every 15 minutes A slower, still sub-hourly cadence at 96 runs a day. The next step down when the ten-minute poll is mostly finding nothing new.
• */10 * * * 1-5 Every 10 minutes, Monday through Friday The same ten-minute cadence, but only Monday through Friday. Removes 28 percent of the invocations at no cost when the weekend produces no work.
• 5,15,25,35,45,55 * * * * At 5, 15, 25, 35, 45, and 55 minutes past the hour The same ten runs an hour, shifted five minutes off the top. The list form is the only way to break the step's anchor at minute 0.