Runs in your browser. Your files and text never leave your device - nothing is uploaded.
Every 15 minutes
Next 8 run times
- Fri, Oct 16, 2026, 11:30 PM
- Fri, Oct 16, 2026, 11:45 PM
- Sat, Oct 17, 2026, 12:00 AM
- Sat, Oct 17, 2026, 12:15 AM
- Sat, Oct 17, 2026, 12:30 AM
- Sat, Oct 17, 2026, 12:45 AM
- Sat, Oct 17, 2026, 01:00 AM
- Sat, Oct 17, 2026, 01:15 AM
Standard 5-field cron syntax: minute, hour, day of month, month, day of week. Next run times are computed in your browser's local timezone.
What is the cron expression for every 15 minutes?
*/15 * * * * runs a job every 15 minutes, at minutes 0, 15, 30 and 45 of every hour. It is identical to writing 0,15,30,45 * * * *. The job fires four times an hour, 96 times a day and 35,040 times across 2026, because every day of the year matches.
*/15 * * * * field by field
| Field | Allowed | Value | Selects |
|---|---|---|---|
| Minute | 0-59 | */15 | minutes 0, 15, 30 and 45, 4 times an hour |
| Hour | 0-23 | * | every hour of the day (0-23) |
| Day of month | 1-31 | * | any date |
| Month | 1-12 or JAN-DEC | * | every month |
| Day of week | 0-6 or SUN-SAT (0 = Sunday; many crons also accept 7) | * | any weekday |
With both day fields left as *, every calendar date qualifies, so only the minute and hour decide when it fires.
How often */15 * * * * runs in 2026
- Runs on each matching day: 96.
- Matching days in 2026: 365 of 365.
- Total runs in 2026: 35,040.
- First run of the year: Thu, 1 Jan 2026, 00:00 UTC. Last: Thu, 31 Dec 2026, 23:45 UTC.
These counts use UTC, which has no daylight saving. The run list in the generator shows the next runs in your browser's own time zone instead.
The same schedule in other schedulers
| Scheduler | Write it as | Watch out for |
|---|---|---|
| crontab (Linux, macOS) | */15 * * * * /usr/local/bin/sync-feeds.sh | Add it with crontab -e. In /etc/crontab a user name goes between the time fields and the command. |
| Kubernetes CronJob | schedule: "*/15 * * * *" | Valid as written; startingDeadlineSeconds decides whether a run missed during controller downtime still starts. |
| GitHub Actions | - cron: '*/15 * * * *' | Allowed. The top of the hour is a busy time on Actions, so 5-59/15 is less likely to be delayed. |
| AWS EventBridge | cron(0/15 * * * ? *) | rate(15 minutes) is the alternative, without the alignment to quarter-hours. |
| Quartz | 0 0/15 * * * ? | 0 0/15 * * * ? fires at second 0 of minutes 0, 15, 30 and 45. |
Time zones and daylight saving
Quarter-hour jobs are the most portable schedule there is: every UTC offset in use is a whole multiple of 15 minutes, so :00, :15, :30 and :45 in UTC land on quarter-hours in India (UTC+5:30) and Nepal (UTC+5:45) as well. Daylight saving still changes the daily count on a local-time server: 92 runs on the spring-forward day and 100 on the autumn day, when one hour happens twice.
Common mistakes with */15 * * * *
- Mixing up
*/15and15:15 * * * *runs once an hour at quarter past, not every 15 minutes. - Expecting the 15-minute cycle to start when the job is installed. The schedule is pinned to the clock, so a job added at 10:07 first runs at 10:15, eight minutes later.
- Stacking many quarter-hour jobs on the same four marks. On a shared host, offset them, for example
5-59/15for 5, 20, 35 and 50 past.
Frequently asked questions
*/15 * * * * - Every 15 minutes. Evaluated in UTC, that comes to 35,040 runs in 2026, the first at Thu, 1 Jan 2026, 00:00 UTC.
Yes, in the minute field both select minutes 0, 15, 30 and 45. The step form is shorter and easier to change later, while a list makes the exact minutes obvious and can express uneven spacing such as 0,10,40 that no single step can.
EventBridge: cron(0/15 * * * ? *). Quartz: 0 0/15 * * * ?. EventBridge adds a year field at the end and Quartz a seconds field at the start, and both need ? in one day field - here the day-of-week field, because the schedule names no weekday.
Other common schedules
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026