Every 8 Hours Cron Expression
Runs three times per day at 00:00, 08:00, and 16:00.
0 */8 * * * in POSIX cron
Expression
0 */8 * * *Try it in the tester →Field Breakdown
How It Works
Step value `*/8` in the hour field — fires at hours 0, 8, and 16 of every day.
Example Run Times
- 00:00:00
- 08:00:00
- 16:00:00
- 00:00:00 (next day)
- 08:00:00 (next day)
Frequently Asked Questions
Is `0 0,8,16 * * *` equivalent?
Yes — both produce the same three fire points per day.
0 */8 * * * in Quartz / Spring
Three firings a day — 00:00, 08:00, and 16:00 — carving the day into the same eight-hour thirds a classic shift roster uses. The hour-field step anchors at 0, and since 24 is a multiple of 8, the 16:00-to-midnight wrap keeps the spacing exact.
Quartz / Spring expression
0 0 */8 * * ?Try it in the tester →At second 0, at minute 0, every 8 hours
Unix / POSIX equivalent: 0 */8 * * *
Field Breakdown
Using It with Quartz / Spring
Thrice-daily fits work pegged to shift boundaries or coarse freshness targets: handover summary reports as one operations shift ends, incremental backups dense enough to cap data loss at eight hours, or shipping accumulated logs to cold storage before local disks fill. The wiring is the usual pair — @Scheduled(cron = "0 0 */8 * * ?") in Spring, CronScheduleBuilder.cronSchedule(...) in Quartz. With eight clear hours between runs, even slow jobs finish long before the next slot, so concurrency controls matter less here than at minute-scale cadences.
Quartz-Specific Notes
- →The matched set is exactly {0, 8, 16}; an anchored variant like 0 0 6/8 * * ? slides the whole pattern to 06:00, 14:00, and 22:00 while keeping eight-hour gaps.
- →Common US and European DST transitions touch only the 01:00-03:00 band, so all three of this schedule's fire times exist on transition days.
- →If the three runs serve three different shifts, three separate fixed-hour triggers (one per shift) keep job logic free of time-of-day branching and let each trigger carry its own misfire policy.
Frequently Asked Questions
Can I align the three runs with shifts starting at 06:00?
Yes — anchor the step: 0 0 6/8 * * ? fires at 06:00, 14:00, and 22:00. The slash after a literal starts counting from that hour instead of from 0.
What are the exact fire times of 0 0 */8 * * ??
Midnight, 08:00, and 16:00, each at second and minute zero, in the trigger's timezone. The step anchors at hour 0 and adds 8 until it runs out of day.
Eight hours is a long gap — should I worry about missed runs?
A scheduler offline through one slot loses up to eight hours of coverage, so pick the misfire instruction deliberately: fire-and-proceed recovers the missed backup late, while do-nothing waits for the next aligned slot and accepts the gap.
0 */8 * * * in AWS EventBridge
Three firings a day — 00:00, 08:00, and 16:00 UTC — produced by an 8-hour step in the hour field. Three-a-day maps naturally onto follow-the-sun operations, with one run roughly per global working shift.
AWS EventBridge expression
cron(0 */8 * * ? *)Try it in the tester →Every 8 hours on the hour UTC
Unix / POSIX equivalent: 0 */8 * * *
Field Breakdown
Using It with AWS EventBridge
Teams reach for an eight-hour rule when work should happen once per shift or once per business region: rotating short-lived credentials three times daily, aggregating logs per eight-hour window, reconciling inventory between a warehouse system and a storefront, or producing handover reports for ops teams in successive timezones. The string is a drop-in ScheduleExpression for a rule or an EventBridge Scheduler schedule. The 08:00 UTC run conveniently opens the European workday, while 16:00 UTC lands in the US morning — only the midnight run falls outside everyone's office hours.
AWS-Specific Notes
- →Equivalent list form: cron(0 0,8,16 * * ? *); the step and the list compile to the same three firing hours.
- →Three runs daily totals 1,095 per year — sparse enough that per-invocation cost is negligible and monitoring for missed runs matters more than spend.
- →Eight divides 24 exactly, so the daily pattern never drifts; the same three UTC hours fire every single day, weekends included.
Frequently Asked Questions
How do I align the three runs with my regions' mornings instead of 0/8/16?
List the hours you actually want: cron(0 1,9,17 * * ? *) shifts everything by one hour while preserving the eight-hour spacing. Any three hours mutually eight apart work — 2,10,18 or 7,15,23 are equally valid.
Should this exclude weekends if the shifts only run Monday to Friday?
Constrain day-of-week and move the ? to day-of-month: cron(0 */8 ? * 2-6 *) fires its three daily runs only Monday through Friday, since EventBridge counts Monday as 2 and Friday as 6.
0 */8 * * * in GitHub Actions
Three runs per day — 00:00, 08:00, and 16:00 UTC — one for each traditional eight-hour shift. The */8 step divides the day cleanly, so the anchors are identical every day with no drift.
GitHub Actions expression
0 */8 * * *Try it in the tester →Every 8 hours on the hour UTC
Unix / POSIX equivalent: 0 */8 * * *
Field Breakdown
Using It with GitHub Actions
Declared as on: schedule: - cron: "0 */8 * * *" in a default-branch workflow, the thrice-daily rhythm maps loosely onto a follow-the-sun pattern: 00:00 UTC arrives at 09:00 in Tokyo, 08:00 UTC lands in the European morning, and 16:00 UTC reaches the Americas mid-workday. Teams use it for triage digests delivered once per regional shift, refreshing dependency caches ahead of each region's CI rush, and rotating short-lived credentials that expire on a half-day scale.
GitHub-Specific Notes
- →All three runs come from the same cron line, so github.event.schedule contains the identical string for each — a job that must know which shift fired it should read the clock, for example with date -u +%H.
- →Because 8 divides 24, the anchors never wander: the spacing is a uniform eight hours every day of the year.
- →To move the trio off the midnight anchor, use a range-step like "0 6-23/8 * * *", which fires at 06:00, 14:00, and 22:00 UTC.
Frequently Asked Questions
Inside the job, how do I tell the midnight run from the 16:00 run?
Check the time yourself — date -u +%H at the start of the job returns 00, 08, or 16. The event payload can't distinguish them because all three ticks come from one cron entry.
Can three daily runs hit 9am in Tokyo, London, and New York?
Approximately, with an explicit hour list instead of the step: "0 0,8,13 * * *" matches 09:00 JST, 09:00 BST, and 09:00 EDT during the northern summer. Tokyo stays exact year-round, but London and New York drift an hour when daylight saving ends, since the schedule itself is fixed in UTC.