Quick answer
The cron expression for every 2 minutes is */2 * * * *. The */2 step in the minute field keeps every second value from 0 to 59, so the job fires on even minutes: :00, :02, :04 through :58. That is 30 runs an hour and 720 a day. To run on odd minutes instead, use 1-59/2 * * * *.
- Live next runs
- Any time zone
- Field-by-field breakdown
- Seven platform snippets
- Daylight saving aware
How to use this schedule
- 1Copy
*/2 * * * *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 */2 * * * * mean?
*/2 is a step over the whole minute range. A step always starts at the field's minimum, which is 0 for minutes, so the job lands on even minutes. Because 60 divides evenly by 2, the rhythm survives the hour boundary: :58 is followed by :00, exactly two minutes later.
To move the job onto odd minutes, start the range at 1:
| Expression | Minutes | Runs per hour |
|---|---|---|
*/2 * * * * | 0, 2, 4 … 58 | 30 |
1-59/2 * * * * | 1, 3, 5 … 59 | 30 |
0-58/2 * * * * | 0, 2, 4 … 58 | 30 |
This pair is handy when two jobs share a resource. Schedule one on even minutes and the other on odd minutes, and they take turns without ever starting in the same minute.
When is every 2 minutes the right interval?
Two minutes sits between "as fast as cron goes" and "every five". It fits jobs where a short delay is fine but five minutes feels sluggish:
- Polling a slow status endpoint for long-running exports
- Near-real-time sync between two systems without webhooks
- Alert checks where a two-minute detection window is acceptable
The worst-case delay is easy to reason about: an event that arrives just after a run waits up to two minutes for the next one. If that is too long, go to every minute; if it is comfortably fine, every 5 minutes cuts the run count from 720 to 288 a day.
One platform note: GitHub Actions does not schedule workflows more often than every 5 minutes, so this interval needs a real cron daemon, a Kubernetes CronJob or another scheduler.
What does each field in */2 * * * * mean?
| Field | Value | Allowed | Meaning |
|---|---|---|---|
| Minute | */2 | 0–59 | every 2 minutes: :00, :02, :04 … :58 |
| 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 every even minute (:00, :02, :04 … :58) of every hour, every day.
How do I adjust */2 * * * * to my own schedule?
Small edits to */2 * * * * cover most real-world needs:
| Expression | What it does |
|---|---|
1-59/2 * * * * | Every 2 minutes on odd minutes (:01, :03 … :59) |
*/2 8-20 * * * | Every 2 minutes from 08:00 to 20:58 |
*/2 * * * 1-5 | Every 2 minutes on weekdays only |
0-58/2 * * * * | The same as */2, written as an explicit range |
*/3 * * * * | Every 3 minutes (:00, :03 … :57) |
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 minute · Every 5 minutes · Every 10 minutes · Every 2 hours
Browse all schedules in the cron schedule library.
How do I run */2 * * * * in crontab, GitHub Actions, Kubernetes and the cloud?
| Platform | Write it as | Time zone |
|---|---|---|
| Linux crontab | */2 * * * * | Server's time zone; CRON_TZ= in cronie |
| GitHub Actions | - cron: "*/2 * * * *" | UTC by default; add timezone: (IANA name). Runs at most every 5 minutes |
| Kubernetes CronJob | schedule: "*/2 * * * *" | Set timeZone: (1.27+) |
| Cloudflare Workers | */2 * * * * | UTC only; numbers weekdays from 1 = Sunday, so use names |
| Vercel Cron Jobs | */2 * * * * | UTC only; more than once a day needs Pro (Hobby: once a day) |
| AWS EventBridge Scheduler | cron(*/2 * * * ? *) | Takes a time zone; legacy scheduled rules are UTC only |
| systemd timer | OnCalendar=*-*-* *:0/2:00 | Add a zone after the time, e.g. Europe/London |
In a crontab (crontab -e), the full line looks like this:
*/2 * * * * /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 */2 * * * *?
*/2 * * * *and0 */2 * * *look alike but are worlds apart: the first runs every 2 minutes, the second every 2 hours. Check which field the step sits in.- Two minutes is short enough for a slow network call to push one run into the next. Guard the command with
flock -n /tmp/job.lockso a stuck run doesn't stack up copies. - GitHub Actions won't schedule anything more often than every 5 minutes, so this expression doesn't give you 2-minute runs there.
1/2is Quartz and Kubernetes syntax for odd minutes; Vixie cron and cronie (Linux crontab) reject a step after a single number.1-59/2is the portable spelling.- 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.