The hourly schedule
A cron every hour schedule fires 24 times a day, at minute 0 of each hour. It is the most common
non-daily cadence in any crontab, and the one most likely to be written on autopilot. There are two
equivalent forms — the five fields with a zero in the minute position, and the @hourly shortcut
that crontab expands to exactly that. The panel above starts on the explicit form, because it is the
one you can edit.
Move it off minute zero
An hourly job at minute 0 shares its start with everything else on the machine that thought minute 0 was a sensible default: log rotation, metric flushes, other people's cron entries, and any agent that ships data upstream. The first minute of every hour is busy and the other fifty-nine are not.
Changing the minute is one character. Minute 30 is the obvious alternative, but any unclaimed minute works, and on a fleet of hosts a different minute per host spreads the load without changing the schedule's meaning. Nothing depends on the job starting exactly on the hour unless you have written something downstream that assumes it, which is worth knowing either way.
Every few hours
The step syntax in the hour field is how you go from hourly to less often. Two hours gives you the even hours, six gives you four runs a day at 00:00, 06:00, 12:00 and 18:00, and twelve gives you midnight and midday. These are clean because 2, 6 and 12 divide 24.
Five does not, and that is the trap. A five-hour step produces 00:00, 05:00, 10:00, 15:00 and 20:00, and then the day ends: the gap from the last run to the first run of the next day is four hours, not five. Every day, one interval is short. The same arithmetic that makes a seven-minute step uneven in the minute field makes a five-hour step uneven here, because both fields restart their count at the boundary rather than continuing from the last run.
If you need a gap that does not divide the day, cron cannot express it. Schedule the next run from the end of the previous one instead.
Hourly jobs and the hour that repeats
An hourly schedule meets the daylight saving transition twice a year, and it is the one cadence where both directions hurt. The spring transition removes an hour, so one run never happens; the autumn transition repeats an hour, so one run may happen twice. Neither matters for a job that recomputes a value, and both matter for a job that appends to a ledger or sends a message. If yours is the second kind, make it safe to run twice rather than trying to schedule around the calendar.
Which side of hourly you want
Hourly is a comfortable default and a poor decision when it is unexamined. If the work is worth doing sooner, the 30-minute schedule is the next step down and doubles the runs. If it is a report or a cleanup that nobody reads until morning, a daily midnight job removes 23 runs a day and loses nothing. Whatever you land on, paste it into the cron expression generator and read the sentence before it goes into a crontab.