Cron every 2 minutes: */2 * * * *

A step is applied from the bottom of the field, and the minute field starts at 0, so */2 lands on even minutes and never on odd ones. That is not a rounding artefact, it is the definition: the parser walks 0, 2, 4 up to 59 and collects every value it touches. If you want the odd half of the clock you have to say so with an explicit range, 1-59/2, which starts the walk at 1 instead.

Two minutes is short enough that the previous run may still be going. Unlike a once a minute job the odds are better, but the failure is sneakier: the job runs fine for weeks, then one slow day it crosses the two minute mark and you get overlapping writes with no obvious cause. Wrapping the command in a lock costs nothing and removes the whole class of problem.

Everything on the machine that uses */2 fires at the same instant, and so does everything using */2 on every other machine whose clock is synchronised. If the job talks to a shared API or database, moving to 1-59/2 halves the number of processes hitting it at exactly the same moment for no change in frequency.

During the hour that repeats at the end of daylight saving time, a minute based schedule like this one runs 30 extra times, because the wall clock passes through the same minutes twice. During the hour that is skipped in spring it loses 30 runs. Neither matters for an idempotent check, and both matter a lot for anything that appends to a ledger.