What is the cron expression for every 3 minutes?

The cron expression for every 3 minutes is "*/3 * * * *". Runs every 3 minutes, around the clock.

What should I watch out for when running a cron job every 3 minutes?

3 doesn't divide 60 evenly into the next hour cleanly — but it does divide 60. */3 fires at :00,:03...:57, then :00 again, so spacing is consistent. The trap is mixing it with hour steps: */3 */3 * * * does NOT mean 'every 3 min during every 3rd hour' the way people expect — the minute and hour fields are independent ANDs, not a combined cadence. Overlap protection is non-optional at this frequency. 480 runs/day means a job that hangs once will stack copies; wrap it in flock -n /tmp/sync.lock so a stuck run blocks new ones instead of forking a pile-up.

Cron expression for Every 3 minutes

*/3 * * * *

Runs every 3 minutes, around the clock.

Next 5 runs (your local time)

These are shown in your browser’s timezone. The job itself runs in the scheduler’s timezone — often UTC — so the real run time can differ.

What people actually schedule with `/3 * * *`

Scraping a rate-limited endpoint where every-2 trips throttling but every-5 is too slow to catch fast-moving data
Re-syncing a cache or materialized view that's expensive enough you don't want it every minute but stale at 5
Retrying a flaky outbound webhook delivery on a tight loop without overwhelming the receiver

Use `/3 * * *` on your platform

It’s the same 5-field expression everywhere — what changes is where you put it and which timezone it runs in.

Linux / crontab

*/3 * * * * /path/to/your-command

Runs in the server’s local timezone — check it with timedatectl. Full field reference: crontab(5) man page.

GitHub Actions

on:
  schedule:
    - cron: "*/3 * * * *"

GitHub Actions always runs scheduled jobs in UTC — there is no timezone setting, and runs can be delayed under load (official docs).

Kubernetes CronJob

spec:
  schedule: "*/3 * * * *"

Defaults to UTC. Set spec.timeZone (Kubernetes 1.27+) for a specific zone — see the CronJob docs.

Quartz / Spring `@Scheduled`

Quartz uses 6 fields (seconds first): 0 */3 * * * *. Watch out: Quartz day-of-week is 1=SUN … 7=SAT (not 0–6), and day-of-month / day-of-week use ? — double-check if your schedule touches those fields (Quartz cron reference).

Gotchas with every 3 minutes schedules

3 doesn't divide 60 evenly into the next hour cleanly — but it does divide 60. */3 fires at :00,:03...:57, then :00 again, so spacing is consistent. The trap is mixing it with hour steps: */3 */3 * * * does NOT mean 'every 3 min during every 3rd hour' the way people expect — the minute and hour fields are independent ANDs, not a combined cadence.
Overlap protection is non-optional at this frequency. 480 runs/day means a job that hangs once will stack copies; wrap it in flock -n /tmp/sync.lock so a stuck run blocks new ones instead of forking a pile-up.
Drift between cron and the data source. If your 3-minute job assumes 'fetch everything since 3 minutes ago' using date, a delayed start (busy server) means you fetch a 4-minute window and double-process the overlap — track a real last-seen cursor, not wall-clock subtraction.

Will you know if this job silently fails?

Cron jobs fail quietly — a server reboots, a path changes, or an error code is ignored — and nobody notices until the data is missing. A cron monitor (a dead-man’s-switch) alerts you when a scheduled job does not check in on time.

Monitor your cron jobs with UptimeRobot →

Disclosure: this is an affiliate link — we may earn a commission if you sign up, at no extra cost to you.

Is `/3 * * *` the right schedule?

If 2-minute latency would actually help, every 2 minutes is the next step up; if you're just being cautious about API limits, every 5 minutes is the safer default and rarely noticed by users.

Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule: