Runs in your browser. Your files and text never leave your device - nothing is uploaded.
Every 30 minutes
Next 8 run times
- Fri, Oct 16, 2026, 11:30 PM
- Sat, Oct 17, 2026, 12:00 AM
- Sat, Oct 17, 2026, 12:30 AM
- Sat, Oct 17, 2026, 01:00 AM
- Sat, Oct 17, 2026, 01:30 AM
- Sat, Oct 17, 2026, 02:00 AM
- Sat, Oct 17, 2026, 02:30 AM
- Sat, Oct 17, 2026, 03:00 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 30 minutes?
*/30 * * * * runs a job every 30 minutes, on the hour and at half past: minutes 0 and 30 of every hour. That is 48 runs a day and 17,520 in 2026. Writing 0,30 * * * * gives exactly the same schedule, while 30 * * * * alone would run only once an hour.
*/30 * * * * field by field
| Field | Allowed | Value | Selects |
|---|---|---|---|
| Minute | 0-59 | */30 | minutes 0 and 30, 2 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 */30 * * * * runs in 2026
- Runs on each matching day: 48.
- Matching days in 2026: 365 of 365.
- Total runs in 2026: 17,520.
- First run of the year: Thu, 1 Jan 2026, 00:00 UTC. Last: Thu, 31 Dec 2026, 23:30 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) | */30 * * * * /usr/local/bin/refresh-cache.sh | Add it with crontab -e. In /etc/crontab a user name goes between the time fields and the command. |
| Kubernetes CronJob | schedule: "*/30 * * * *" | Valid; under the default concurrencyPolicy: Allow, a run lasting past 30 minutes overlaps the next one. |
| GitHub Actions | - cron: '*/30 * * * *' | Allowed; both runs each hour are in UTC unless a timezone key sits next to the cron line. |
| AWS EventBridge | cron(0/30 * * * ? *) | rate(30 minutes) works too, but is not tied to :00 and :30. |
| Quartz | 0 0/30 * * * ? | Fires at :00:00 and :30:00 of every hour. |
Time zones and daylight saving
Half-hour marks line up in nearly every zone, but a UTC schedule lands at quarter past and quarter to the local hour in Nepal (UTC+5:45) and on the Chatham Islands (UTC+12:45). On a local-time server, daylight saving gives 46 runs on the spring-forward day and 50 on the autumn day. If the job feeds a dashboard that expects exactly 48 points a day, schedule it in UTC.
Common mistakes with */30 * * * *
30 * * * *runs once an hour at half past, not every 30 minutes.- Reaching for
*/90to mean every 90 minutes. The minute field stops at 59, so a step cannot span hours; a 90-minute cycle needs two lines,0 0-21/3 * * *and30 1-22/3 * * *. - Long runs: if one execution can take more than 30 minutes, two copies overlap. Guard with
flock -nor KubernetesconcurrencyPolicy: Forbid.
Frequently asked questions
*/30 * * * * - Every 30 minutes. Evaluated in UTC, that comes to 17,520 runs in 2026, the first at Thu, 1 Jan 2026, 00:00 UTC.
Restrict the hour and weekday fields: */30 9-17 * * 1-5 runs at :00 and :30 from 09:00 to 17:30, Monday to Friday. To stop at 17:00 exactly, use 9-16 in that line and add a separate 0 17 * * 1-5 line.
EventBridge: cron(0/30 * * * ? *). Quartz: 0 0/30 * * * ?. 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