Cron: Every 15 Minutes
*/15 * * * * runs on the quarter hour — :00, :15, :30, :45 — four times per hour. It aligns naturally with how most people think about time in chunks, which makes it a popular choice for reports, digest emails, and moderate-frequency background jobs.
*/15 * * * *
Examples & Variations
Common Mistakes
- Expecting */15 to run relative to deploy time — it always aligns to :00/:15/:30/:45 of the clock, not to whenever the crontab entry was written.
- Choosing 15 minutes as an arbitrary default without checking whether your users actually need data that fresh — longer intervals often work fine and cost less.
- Not handling daylight saving time transitions on systems where cron runs in local time — a 15-minute job can run twice or not at all during a clock change, depending on server configuration.
Best Practices
- For anything downstream of an external API, 15-minute polling is usually gentle enough to avoid rate-limit issues while staying reasonably fresh.
- If DST matters to your job, run your cron daemon in UTC and convert for display, avoiding the twice-a-year ambiguity of local time transitions.
- Combine with an hour range to avoid unnecessary overnight runs if the job only serves daytime traffic.
Frequently Asked Questions
- Why does */15 always align to :00, :15, :30, :45?
- Step values in cron are computed from the field's minimum (0), not from an arbitrary starting point — so */15 in the minute field always expands to 0, 15, 30, 45 regardless of when the schedule was created.
- Is every 15 minutes a good interval for a cron-based CI job?
- It's reasonable for lightweight checks (linting, smoke tests) but most teams trigger CI on push/PR events instead of polling on a timer, reserving cron schedules for nightly or periodic jobs that aren't tied to code changes.
- How do I run every 15 minutes only on weekdays?
- Add a day-of-week restriction: */15 * * * 1-5 keeps the quarter-hour cadence but only fires Monday through Friday.