Quick answer
The cron expression for every 10 minutes is */10 * * * *. The */10 step in the minute field matches 0, 10, 20, 30, 40 and 50, so the job runs six times an hour and 144 times a day, always on the same clock minutes. The other four fields are asterisks, so it runs every hour of every day.
- Live next runs
- Any time zone
- Field-by-field breakdown
- Seven platform snippets
- Daylight saving aware
How to use this schedule
- 1Copy
*/10 * * * *with the Copy expression button. - 2Check Next runs in your time zone to confirm it fires when you expect, including around daylight saving changes.
- 3Pick your platform under Use it on your platform and copy the ready-made crontab line, workflow, manifest or timer.
- 4Need a different time or day? Click Customize to open it in the cron expression generator and change any field.
What does */10 * * * * mean?
The step */10 walks the minute range 0–59 in tens, starting at 0. It is exactly the same as the list 0,10,20,30,40,50, just shorter to write.
Like every cron schedule, it is anchored to the clock. Save the crontab at 14:07 and the first run is at 14:10, not 14:17. Because 10 divides 60 evenly, the spacing never changes: :50 is followed by :00 ten minutes later. Steps that don't divide 60, such as */7, leave a short gap at the top of every hour.
You can slide the whole rhythm without changing its spacing by starting the range somewhere else:
| Expression | Runs at |
|---|---|
*/10 * * * * | :00, :10, :20, :30, :40, :50 |
3-59/10 * * * * | :03, :13, :23, :33, :43, :53 |
5-59/10 * * * * | :05, :15, :25, :35, :45, :55 |
What is a 10-minute schedule good for?
Ten minutes is frequent enough to feel current and sparse enough to be cheap. Typical jobs:
- Importing new orders or leads from a system without webhooks
- Rebuilding a cached feed, a leaderboard or a sitemap
- Sending batched notification digests instead of one message per event
- Checking that a scheduled export actually landed in storage
Budget it in calls: 144 runs a day means one API call per run uses 144 requests a day, and ten calls per run use 1,440. If a partner API allows 1,000 requests a day, that second design will not fit.
It is also a sensible choice on GitHub Actions, where every 5 minutes is the floor and scheduled runs can start late. Need it fresher? Try every 5 minutes. Can it wait? Every 15 minutes cuts the run count by a third.
What does each field in */10 * * * * mean?
| Field | Value | Allowed | Meaning |
|---|---|---|---|
| Minute | */10 | 0–59 | every 10 minutes: :00, :10, :20, :30, :40 and :50 |
| Hour | * | 0–23 | every hour |
| Day of month | * | 1–31 | every day of the month |
| Month | * | 1–12, JAN–DEC | every month |
| Day of week | * | 0–7 (0 and 7 are Sunday), SUN–SAT | every day of the week |
Read together: At minutes :00, :10, :20, :30, :40 and :50 of every hour, every day.
How do I adjust */10 * * * * to my own schedule?
Small edits to */10 * * * * cover most real-world needs:
| Expression | What it does |
|---|---|
5-59/10 * * * * | Every 10 minutes, offset to :05, :15 … :55 |
*/10 9-17 * * 1-5 | Every 10 minutes from 09:00 to 17:50, Monday to Friday |
0,10,20,30,40,50 * * * * | The same schedule written as an explicit list |
*/10 0-6 * * * | Every 10 minutes overnight, from 00:00 to 06:50 |
*/15 * * * * | Every 15 minutes, a little less often |
Need something else? Click Customize at the top of the page to open this schedule in the cron expression generator and change any field.
Related schedules: Every 5 minutes · Every 15 minutes · Every 30 minutes · Every hour
Browse all schedules in the cron schedule library.
How do I run */10 * * * * in crontab, GitHub Actions, Kubernetes and the cloud?
| Platform | Write it as | Time zone |
|---|---|---|
| Linux crontab | */10 * * * * | Server's time zone; CRON_TZ= in cronie |
| GitHub Actions | - cron: "*/10 * * * *" | UTC by default; add timezone: (IANA name) |
| Kubernetes CronJob | schedule: "*/10 * * * *" | Set timeZone: (1.27+) |
| Cloudflare Workers | */10 * * * * | UTC only; numbers weekdays from 1 = Sunday, so use names |
| Vercel Cron Jobs | */10 * * * * | UTC only; more than once a day needs Pro (Hobby: once a day) |
| AWS EventBridge Scheduler | cron(*/10 * * * ? *) | Takes a time zone; legacy scheduled rules are UTC only |
| systemd timer | OnCalendar=*-*-* *:0/10:00 | Add a zone after the time, e.g. Europe/London |
In a crontab (crontab -e), the full line looks like this:
*/10 * * * * /path/to/job.sh >> /var/log/job.log 2>&1The live panel at the top of the page builds complete, copy-ready files for each platform (workflow, CronJob manifest, wrangler.toml, vercel.json, AWS CLI and systemd units) and can shift the schedule to UTC for platforms that need it.
What can go wrong with */10 * * * *?
- A slow upstream API can push one run past the next start. Protect the command with
flock -n /tmp/job.lock your-commandso runs never overlap. */10in the hour field is not a steady 10-hour rhythm:0 */10 * * *fires at 00:00, 10:00 and 20:00, then again at midnight after only 4 hours.- If the job processes "the last 10 minutes" of data, compute the window from the scheduled time or the last successful run, not from the moment it starts. Late starts otherwise create gaps and double counts.
- Scheduled GitHub Actions workflows can start late under load, so treat */10 there as roughly every 10 minutes, not exactly.
- In a zone with daylight saving time, a schedule with
*in the minute or hour field follows the wall clock: the spring-forward night loses an hour of runs and the fall-back night repeats one. Servers on UTC never see this.
Frequently asked questions
Last updated by the Playxoft engineering team.