Cron every 2 minutes

*/2 * * * * runs a job every two minutes, around the clock. Only the minute field is set: */2 steps through 0 to 59 two at a time, so it picks every even minute, 30 runs an hour and 720 a day.

When it fires

On the even minutes of the clock, not two minutes after you install it. Checked at 09:58 UTC, the next five runs are:

10:00  10:02  10:04  10:06  10:08

For the odd minutes instead, start the step at 1: 1-59/2 * * * * runs at 09:59, 10:01, 10:03 and so on. Two jobs on those two lines take turns and never start in the same minute.

Runs that overlap

Two minutes is short. A job that sometimes takes three is still running when cron starts the next copy, and cron doesn’t check. Wrap the command in a lock so a late run skips its turn instead of piling up:

*/2 * * * * flock -n /tmp/sync.lock /usr/local/bin/sync.sh

A systemd timer never starts a second copy of a service that is still running. When the pause between runs matters more than the clock, it can also count from the end of the last run: OnBootSec=2min with OnUnitInactiveSec=2min waits two minutes after each run finishes.

Variations

*/2 9-17 * * 1-5     every 2 minutes, 09:00 to 17:58, Monday to Friday
*/2 * * * 0,6        every 2 minutes on weekends
1-59/2 * * * *       every 2 minutes, on the odd minutes

The same schedule elsewhere

• crontab: */2 * * * * /usr/local/bin/sync.sh, in the server’s timezone unless the crontab sets CRON_TZ.
• GitHub Actions: not possible. Five minutes is the shortest interval a scheduled workflow gets.
• Kubernetes CronJob: schedule: "*/2 * * * *", with concurrencyPolicy: Forbid to skip a run while the last one is still going.
• AWS EventBridge: cron(0/2 * * * ? *), or rate(2 minutes).
• systemd timer: OnCalendar=*:0/2, which systemd-analyze calendar normalizes to *-*-* *:00/2:00.
• Spring @Scheduled: 0 */2 * * * *; Spring’s first field is seconds.