Cron every 2 hours: 0 */2 * * * and the mistakes that break it

Here's how the fields read. The minute field is 0, so every run lands at :00. The hour field is */2, which picks each hour that's a multiple of 2, counted from midnight: 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22. The last three fields are *, so the job runs every day, in every month, on every weekday. A crontab line with a real command looks like this:

0 */2 * * * /usr/local/bin/refresh-cache

The first slip is dropping the leading zero. Write * */2 * * * and the minute field matches every minute, so the job fires once a minute during each even hour. The line still looks almost right, which is why it gets past a quick read. That's 720 runs a day, against 12 with the zero in place, so the broken version floods the log if the job writes any output. The fix is to put the 0 back in front.

The second trap is the hour step. Cron counts steps inside each field, and crontab(5) says "steps are evaluated just within the field they are applied to." So */2 starts over at midnight every day. A step of two divides 24 evenly, so every gap matches the step and the schedule looks right. A step like */5 doesn't divide 24 evenly. It runs at hours 0, 5, 10, 15, 20 each day. The gap from the last of those hours to midnight is shorter than the rest, so a job that needs even spacing will run at uneven intervals. If that gap matters, use a step that divides 24, like */6, which gives hours 0, 6, 12, 18.

Odd hours need a different expression, since */2 only ever lands on even hours. If you want them, like the 1 AM run and the 3 AM run, write 0 1-23/2 * * *. That runs at hours 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, and that's 12 runs a day. It's a handy offset when a second job should use the other hours. Midnight doesn't cause a short gap here, since the odd hours wrap around at the same spacing.

Hours are read on the server's clock. Cron uses the server's local time zone by default, so the even hours are even only on that clock. If the server runs in UTC but your team sits in a zone an odd number of whole hours away, the even UTC hours are odd hours on the team's clock, and the job runs at hours the team didn't plan for. Where your cron supports CRON_TZ, set it above the job line, or convert the hours to UTC by hand. The full story is on the time zone page.

Compare it with its neighbors before you pick it. An hourly job (0 * * * *) runs more often than this one, so pick it only for data that goes stale within the hour. This schedule runs more often than 0 */6 * * *, which runs 4 times a day and suits a report or a sync that can wait a few hours.