What is the cron expression for every 2 minutes?

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

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

The interval doesn't reset across the hour boundary. */2 * * * * matches even minute values (0,2,4...58), so the gap from :58 to the next :00 is the normal 2 minutes — but if you ever switch to an odd-stepping mistake like 1-59/2, you get :59→:01 spacing that drifts. Stick to */2 and verify it lands on even minutes. Overlap still bites at 720 runs/day. A job that occasionally takes 90s will have its next run fire while it's mid-flight; guard with flock -n /tmp/poll.lock yourcmd so the late run skips rather than doubling your API calls.

Cron expression for Every 2 minutes

*/2 * * * *

Runs every 2 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 `/2 * * *`

Polling a payment provider or third-party API for status changes when you need faster reaction than every-5 but can't justify hammering it every minute
Health-checking an internal service and flipping a load-balancer flag before users notice a stall
Draining a small SQS/Redis queue where messages trickle in and 2-minute latency is acceptable to consumers

Use `/2 * * *` 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

*/2 * * * * /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: "*/2 * * * *"

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: "*/2 * * * *"

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 */2 * * * *. 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 2 minutes schedules

The interval doesn't reset across the hour boundary. */2 * * * * matches even minute values (0,2,4...58), so the gap from :58 to the next :00 is the normal 2 minutes — but if you ever switch to an odd-stepping mistake like 1-59/2, you get :59→:01 spacing that drifts. Stick to */2 and verify it lands on even minutes.
Overlap still bites at 720 runs/day. A job that occasionally takes 90s will have its next run fire while it's mid-flight; guard with flock -n /tmp/poll.lock yourcmd so the late run skips rather than doubling your API calls.
Cron mail compounds fast. 720 emails/day from a noisy script will get your cron mail spooler flagged or fill /var/mail; redirect with >/dev/null 2>&1 and alert only on non-zero exit.

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 `/2 * * *` the right schedule?

If you're polling an external API, every 5 minutes cuts request volume 2.5× and most providers prefer it. Only drop to 2 minutes when a real SLA depends on the faster reaction — otherwise it's wasted calls.

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