Every 15 minutes cron: what */15 * * * * means, with a quarter-hour crontab example
Runs in your browser — nothing you paste leaves this page. How we prove that
Cron Expression Tester playground
Five fields — minute, hour, day of month, month, day of week. Macros like @daily are supported too.
Results update as you type — press Enter to run now.
Every 15 minutes.
- Computed in your browser, in your timezone.
`*/15 * * * *` fires four times an hour, on the quarter hours :00, :15, :30 and :45. The engine reads it as: Every 15 minutes.
Field by field
The minute field */15 steps through 0–59 in fifteens, which yields 0, 15, 30 and 45. Hour, day of month, month and day of week are all asterisks, so the four quarter-hour slots repeat around the clock: 96 runs per day. Writing the list out as 0,15,30,45 * * * * is identical and some teams prefer it because nobody has to remember how steps are anchored.
The parser on this page reads the expression as: Every 15 minutes. The next run times in the panel above are computed in your browser, in your own timezone, so they are not printed in this text.
A quarter-hour job in a crontab
A common use is collecting metrics or rotating short-lived caches: */15 * * * * /usr/local/bin/export-usage --since 15m >> /var/log/export-usage.log 2>&1. Notice the job asks for the last 15 minutes of data. If one run fails or the host is down, that window is lost; a job that records the last timestamp it processed recovers by itself.
Remember that % is special in a crontab line (it becomes a newline), so a date +%F inside the command must be written date +\%F.
Timezones and overlap
Interval schedules such as this one are the least affected by daylight saving time: when the clocks jump forward an hour, the four runs of the skipped hour simply never happen, and on the fall-back day the repeated hour usually produces four extra runs. A job that sums usage per run will double-count that hour unless it works from timestamps.
If a run can take longer than 15 minutes, guard it with flock -n or, in a Kubernetes CronJob, concurrencyPolicy: Forbid. Replace is the other option there: it kills the running Job and starts the new one, which suits jobs where only the freshest result matters.
systemd and GitHub Actions
The systemd timer form is OnCalendar=*:0/15, optionally with RandomizedDelaySec=60 to stop a fleet hitting a shared service in the same second. In GitHub Actions, cron: '*/15 * * * *' is valid and is evaluated in UTC; for a related but lighter schedule, every 30 minutes halves the runs, and every 5 minutes triples them.
FAQ
Questions, answered.
Tap a question to expand the answer.
Can I run every 15 minutes but only during working hours?
Yes. Restrict the hour and day-of-week fields, for example */15 9-17 * * 1-5 runs on the quarter hours from 09:00 to 17:45, Monday to Friday, in the timezone the cron daemon uses.
How do I start at :05 instead of :00?
Give the step a starting point: 5-59/15 * * * * runs at :05, :20, :35 and :50.
More free, private DevOps tools.
The Cron Expression Tester is one tool in OpsCanopy — a growing canopy of browser-based validators, converters and testers that never touch a server.
More in Scheduling
Read more about this
- GitHub Actions cron runs in UTC: convert your schedule and check the real next run time GitHub Actions cron timezone UTC explained: why schedule: cron: always fires on UTC, how DST shifts the wall-clock time, and how to check the real next run.
- Reading cron expressions: a field-by-field guide A field-by-field guide to reading cron expressions — the five time fields, ranges, steps, lists and @macros — plus the gotchas that misfire schedules.
New to Linux? Read the Linux guide →
42 free tools, every one offline-capable — opscanopy.com works with no signup and nothing uploaded.
Scheduling on Linux? Pair this with the Cron to systemd Converter, or browse the full tools directory.
Not affiliated with or endorsed by any cron implementation. Format names are used only to describe what this tool reads. OpsCanopy is free and open.