Cron every 15 minutes: */15 * * * *

The quarter hour is the most human of the machine schedules, which is why so much reporting is built on it. Four runs an hour, ninety six a day, and every run lands on a minute a person would think to write down. It is also the coarsest interval most teams will accept for a dashboard that claims to be near live.

Because the schedule is defined in minutes and not in absolute time, a daylight saving change moves the count rather than the alignment. In a zone where the clock jumps forward an hour, four runs simply never happen and the day has 92. In the autumn, when the same wall clock hour is lived through twice, the day has 100. A job that writes one row per run and expects exactly 96 will notice.

This is a good schedule to offset, because the quarter hours are where scheduled work concentrates on almost every system. Using 7-59/15 gives runs at 7, 22, 37 and 52 past, which is still four an hour, still evenly spaced, and lands on minutes that essentially nothing else uses.

Fifteen minutes is also long enough that a run is worth logging individually. At 96 lines a day a plain append only log stays readable for months, and a missing line is easy to spot by eye, which is not true at one minute intervals. Log the start time, the window the run covered, and the row count, and most debugging becomes reading the file.