Every 6 Hours Cron Expression
Runs four times per day: midnight, 6 AM, noon, 6 PM.
0 */6 * * * in POSIX cron
Expression
0 */6 * * *Try it in the tester →Field Breakdown
How It Works
Step value `*/6` in the hour field — fires at 00:00, 06:00, 12:00, and 18:00.
Example Run Times
- 00:00:00
- 06:00:00
- 12:00:00
- 18:00:00
- 00:00:00 (next day)
Frequently Asked Questions
Is `0 0,6,12,18 * * *` equivalent?
Yes — same four fire points, different notation.
0 */6 * * * in Quartz / Spring
Four evenly spaced firings a day: 00:00, 06:00, 12:00, and 18:00. The */6 step in Quartz's third field (hours) divides the day into quarters, with seconds and minutes zeroed.
Quartz / Spring expression
0 0 */6 * * ?Try it in the tester →At second 0, at minute 0, every 6 hours
Unix / POSIX equivalent: 0 */6 * * *
Field Breakdown
Using It with Quartz / Spring
This is backup-and-housekeeping territory — database snapshot kicks, certificate-expiry scans, and bulk export jobs that are too costly to run hourly. In Spring it's commonly paired with the zone attribute, @Scheduled(cron = "0 0 */6 * * ?", zone = "America/Chicago"), so the 06:00 run lands before the business day regardless of where the container runs. Standalone Quartz achieves the same with CronScheduleBuilder's inTimeZone(TimeZone.getTimeZone("America/Chicago")).
Quartz-Specific Notes
- →The explicit list 0 0 0,6,12,18 * * ? fires at identical times and is arguably clearer to reviewers unfamiliar with hour-field steps.
- →Without a timezone on the trigger, Quartz uses the JVM default — a container rebuilt with TZ=UTC will silently shift all four runs.
- →Six-hour gaps make misfire policy consequential: after a 7-hour outage, FIRE_ONCE_NOW runs one catch-up execution, while DO_NOTHING waits for the next aligned slot.
Frequently Asked Questions
Are the firings at 00/06/12/18 in UTC?
Only if the JVM default timezone is UTC or you set one explicitly. Quartz evaluates cron fields against the trigger's TimeZone (or @Scheduled's zone attribute), not UTC by definition.
Can I shift this to 03:00, 09:00, 15:00, 21:00?
Yes — use a start offset with a step: 0 0 3/6 * * ?. The step counts from hour 3 instead of hour 0.
0 */6 * * * in AWS EventBridge
Four invocations per day — at exactly 00:00, 06:00, 12:00, and 18:00 UTC — come out of this */6 hour step. Quarter-daily is a natural rhythm for global services because the four runs spread evenly across worldwide business hours.
AWS EventBridge expression
cron(0 */6 * * ? *)Try it in the tester →Every 6 hours on the hour UTC
Unix / POSIX equivalent: 0 */6 * * *
Field Breakdown
Using It with AWS EventBridge
Hand the expression to PutRule or to EventBridge Scheduler's CreateSchedule and attach the target ARN: Step Functions for multi-step pipelines, Lambda for lighter sweeps, SQS when consumers should pull at their own pace. Six-hourly jobs frequently rebuild CloudFront-cached API responses, prune expired sessions from ElastiCache or DynamoDB, and roll up six hours of raw events into hourly aggregates for BI tools. The fixed UTC anchor times make handoffs between follow-the-sun ops teams predictable.
AWS-Specific Notes
- →Fire times never vary: 00:00, 06:00, 12:00, 18:00 UTC, every day of every month thanks to the wildcards and the ? in day-of-week.
- →Each run is responsible for a six-hour data window; pass the event's time field (the scheduled timestamp) to the target so reruns process the same window deterministically.
- →rate(6 hours) drifts off these round anchors because it measures from creation time — the cron form is the only way to pin the four daily slots.
Frequently Asked Questions
How do I get four daily runs at 03:00, 09:00, 15:00, 21:00 instead?
Shift the step start: cron(0 3/6 * * ? *). The hour field's value/step form begins at 3 and adds 6 repeatedly within the day.
Does the scheduled event tell my Lambda which of the four slots fired it?
Yes. The event JSON includes a time field with the scheduled UTC timestamp (e.g. 12:00:00Z), which you can parse to pick the data window rather than relying on the function's own clock.
0 */6 * * * in GitHub Actions
Four evenly spaced runs per day — 00:00, 06:00, 12:00, and 18:00 UTC — from a single */6 step in the hour field. For GitHub Actions this quarter-day rhythm is the textbook schedule for nightly-grade work that benefits from a few intraday refreshes.
GitHub Actions expression
0 */6 * * *Try it in the tester →Every 6 hours on the hour UTC
Unix / POSIX equivalent: 0 */6 * * *
Field Breakdown
Using It with GitHub Actions
It lives in workflow YAML as on: schedule: - cron: "0 */6 * * *" and, like all schedules, runs from the default branch's workflow file only. Six-hourly is the natural fit for long integration-test suites against live services, regenerating GitHub Pages content from APIs, and pruning old workflow artifacts with actions/github-script. The four fixed times conveniently straddle business hours across US, European, and Asian timezones, which is why globally distributed projects gravitate to it.
GitHub-Specific Notes
- →Fire times are anchored to 00/06/12/18 UTC and never shift for daylight saving — the local equivalent in DST-observing regions moves twice a year while the workflow does not.
- →All four ticks start at minute :00; for the 00:00 run especially, expect the platform's worst congestion. "31 */6 * * *" keeps the spacing with calmer slots.
- →A public repository idle for 60 days loses this schedule automatically — four-times-daily activity from the workflow itself does not count as repository activity for that timer.
Frequently Asked Questions
Do scheduled runs from this workflow reset the 60-day inactivity clock?
No. GitHub's inactivity check looks at repository activity such as commits, not at scheduled workflow runs — an otherwise untouched public repo gets its schedule disabled even though the workflow ran four times daily.
Can I make the four runs hit 9am in my timezone?
Not directly — schedules are UTC-only with no timezone setting. Compute the UTC hours that correspond to your local targets and list them explicitly, e.g. 0 3,9,15,21 * * * for UTC+3 targets, accepting that DST shifts will move local times.