Cron every 5 minutes: */5 * * * *

Five divides 60 four times over, so this expression produces a perfectly even twelve runs an hour with no awkward gap when the hour rolls over. That regularity, plus the fact that five minutes is short enough to feel responsive and long enough for most scripts to finish, is why it turns up more than any other step schedule.

Its popularity is also its weakness. Minute 0 of every hour is already the busiest minute on any server: it carries the hourly jobs, the quarter hour jobs, the half hour jobs and every other */5. If your five minute job reads a shared database or calls a rate limited API, the run at :00 competes with all of them. Moving to 2-59/5 keeps the twelve runs and puts them on minutes nobody else uses.

At twelve runs an hour a job that takes four minutes is fine and a job that takes six is a slow motion disaster, because each run starts before the previous one has finished and the backlog grows by one process every five minutes until something falls over. Measure the worst case runtime, not the average, and if it is anywhere near five minutes either lock the job or lengthen the interval.

Data pipelines built on this schedule usually want the five minute window as a query bound, not just as a trigger. Deriving the window from the wall clock inside the script, rather than from when the script happened to start, makes a delayed run still cover the right period and makes a skipped run visible as a gap instead of as silently missing rows.