Cron every 3 minutes: */3 * * * *

Three is one of the divisors of 60, so this schedule has the property that a lot of step schedules do not: the interval between the last run of one hour and the first run of the next is the same as every other interval. The final match is minute 57, the next is minute 0 of the following hour, and the gap is three minutes like all the rest. Compare that with a step of 7, where the hour boundary introduces a short gap.

Three minutes is a common choice for health checks that feed an alerting rule needing two or three consecutive failures before it pages. At this rate a genuine outage is confirmed in six to nine minutes, which is usually the right trade between noise and delay. Going to one minute triples the check volume without moving that number much, because the alert rule, not the schedule, sets the floor.

The whole cluster of jobs on this schedule lands on minute 0 of every hour together, along with every hourly job, every */5, every */15 and everything else aligned to the top of the hour. If the run at :00 is consistently the slow one, that pile up is why. Shifting to 1-58/3 keeps twenty runs an hour and moves all of them off the crowded minute.

Nothing about this expression restricts the date, so it also runs through the night, on weekends and on the day you take the service down for maintenance. If the job logs an error when the service is unavailable, a planned outage produces several hundred error lines, which is worth knowing before you set an alert on the log volume.