Cron every 20 minutes: */20 * * * *

Twenty divides an hour into three equal pieces, so the schedule is even across the hour boundary and easy to reason about: minute 0, minute 20, minute 40, then minute 0 of the next hour. Three runs an hour is the point where the fixed cost of starting the job, loading an interpreter, opening connections, reading configuration, stops dominating the useful work.

That startup cost is the usual reason to choose twenty over ten or five. A script that spends eight seconds getting ready and two seconds working is wasting eighty percent of its runtime at every frequency, but at three runs an hour the absolute waste is thirty seconds a day rather than several minutes, and nobody has to rewrite it as a daemon.

The trade is latency. Anything that arrives one minute after a run begins waits nineteen minutes for the next one, so this schedule suits work with a tolerance measured in tens of minutes: cache warming, reconciliation, backfilling a search index. It does not suit anything a person is sitting and waiting for.

Because the three matched minutes include minute 0, the schedule collides with the hourly pile up once every hour rather than once every twenty minutes. Offsetting to 5-59/20 moves all three runs to 5, 25 and 45 past and removes that one collision, which is the cheapest possible fix if the top of the hour is where your database is busiest.