Skip to content

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

Example

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.

Timezone
fig. 04 — cron-expression-tester · scheduling Valid
Result

Every 15 minutes.

Minute*/15
Hour*
Day of month*
Month*
Day of week*
Next runs
  • 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.

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.

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.

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.