Cron every 10 minutes: */10 * * * *

Ten minutes is the point at which a polling job stops being a load concern and starts being a latency concern. Six runs an hour is light enough that nobody notices it on a graph, but the average item waits five minutes before it is picked up, which is the number to check against whatever the job is feeding. If five minutes of lag is acceptable this is usually the right schedule.

The minutes matched are the six that end in a zero, which is also where most humans set manual reminders and where many managed schedulers default. That makes the top and the tens of the hour crowded, so if the job shares a database with anything else on the same cadence, an offset such as 3-59/10 removes the contention without changing the frequency.

For jobs that call a rate limited API, this schedule gives a convenient budget. Six runs an hour means a job may make up to ten calls per run and stay under a limit of sixty an hour, with no burst handling needed. That arithmetic breaks the moment you run the same crontab on a second host, because the limit is usually per account rather than per machine.

Ten minute jobs are long enough that people stop wrapping them in locks, which is exactly when a job that normally takes ninety seconds starts taking twelve minutes because an upstream service is slow. The runtime of a polling job is rarely controlled by the polling job, so treat overlap protection as a property of the schedule rather than of the script.