Every 12 Hours Cron Expression
Runs twice per day: midnight and noon.
0 */12 * * * in POSIX cron
Expression
0 */12 * * *Try it in the tester →Field Breakdown
How It Works
Step value `*/12` in the hour field — fires at 00:00 and 12:00 every day.
Example Run Times
- 00:00:00
- 12:00:00
- 00:00:00 (next day)
- 12:00:00 (next day)
- 00:00:00 (day after)
Frequently Asked Questions
Is `0 0,12 * * *` clearer?
Both forms are valid; the explicit list is sometimes preferred for readability.
0 */12 * * * in Quartz / Spring
Two firings per day, at midnight and noon. In a 0-23 hour field, */12 can only match hours 0 and 12, making this the standard Quartz idiom for a twice-daily job.
Quartz / Spring expression
0 0 */12 * * ?Try it in the tester →At second 0, at minute 0, every 12 hours
Unix / POSIX equivalent: 0 */12 * * *
Field Breakdown
Using It with Quartz / Spring
Twice-daily fits digest emails, currency-rate refreshes, and compliance snapshots that need a morning and evening data point. Spring developers attach it with @Scheduled(cron = "0 0 */12 * * ?") on a @Component method; on the Quartz side it usually rides a durable JobDetail so the trigger survives scheduler restarts via the JobStore. If the two runs do meaningfully different work (say, open-of-day versus close-of-day), prefer two separate triggers with fixed hours over branching inside one job.
Quartz-Specific Notes
- →0 0 0,12 * * ? is the exact same schedule written as a list — choose whichever your team finds more readable.
- →Each firing happens at second 0, minute 0 sharp; with twelve-hour gaps, even multi-minute job durations cause no overlap risk.
- →A scheduler offline from 11:00 to 13:30 misses the noon slot; whether that run is made up immediately or skipped is decided entirely by the trigger's misfire instruction.
Frequently Asked Questions
How do I pin the noon run to a specific timezone?
In Quartz call .inTimeZone(TimeZone.getTimeZone("Asia/Tokyo")) on the CronScheduleBuilder; in Spring set zone = "Asia/Tokyo" on @Scheduled. Otherwise both firings follow the JVM default zone.
Could I run at 08:00 and 20:00 instead of 00:00 and 12:00?
Yes — either list them (0 0 8,20 * * ?) or step from an offset (0 0 8/12 * * ?). Both yield exactly 08:00 and 20:00.
0 */12 * * * in AWS EventBridge
Two runs a day, twelve hours apart: the */12 hour step matches only 00:00 and 12:00 UTC. This twice-daily cadence is common for jobs that bracket a global business day — one run before Asia-Pacific mornings, one before the Americas.
AWS EventBridge expression
cron(0 */12 * * ? *)Try it in the tester →Every 12 hours on the hour UTC
Unix / POSIX equivalent: 0 */12 * * *
Field Breakdown
Using It with AWS EventBridge
Place the string in the ScheduleExpression of an EventBridge rule via the console, CLI, or CloudFormation, and target whatever does the work — a Lambda for config refreshes, an ECS RunTask for container-heavy report builds, or Step Functions for anything with retries and branching. Twelve-hour schedules suit vulnerability-definition downloads, currency and pricing table refreshes, and digest emails compiled from half a day of activity. Pairing both runs against one rule keeps the morning and evening jobs in lockstep.
AWS-Specific Notes
- →Only hours 0 and 12 match, so the rule fires at midnight and noon UTC — 730 invocations a year, nothing in between.
- →There is no way to express e.g. 09:00 and 21:00 with */12; use the start/step form cron(0 9/12 * * ? *) or list them as cron(0 9,21 * * ? *).
- →If the noon run reprocesses data the midnight run already handled, remember at-least-once delivery means even a single slot can occasionally invoke twice — idempotency matters more than at higher frequencies because each run is bigger.
Frequently Asked Questions
Can I make the two daily runs land at 8am and 8pm local time year-round?
Not with a classic rule, which is UTC-only and ignores DST. Create an EventBridge Scheduler schedule with cron(0 8,20 * * ? *) and ScheduleExpressionTimezone set to your zone.
Is cron(0 */12 * * ? *) the same as cron(0 0,12 * * ? *)?
Functionally yes — stepping by 12 from hour 0 yields exactly 0 and 12. The explicit list form is arguably clearer to the next person reading your CloudFormation template.
0 */12 * * * in GitHub Actions
Two runs per day, twelve hours apart: */12 in the hour field matches 00:00 and 12:00 UTC and nothing else. On GitHub Actions this twice-daily beat suits jobs that are too heavy for hourly scheduling but too time-sensitive to wait a full day.
GitHub Actions expression
0 */12 * * *Try it in the tester →Every 12 hours on the hour UTC
Unix / POSIX equivalent: 0 */12 * * *
Field Breakdown
Using It with GitHub Actions
Configure it as on: schedule: - cron: "0 */12 * * *" inside a workflow file on the default branch. Twice-daily workflows typically handle full-repository CodeQL or dependency scans, syncing a downstream mirror, or compiling morning-and-evening digest issues from project activity. Pairing the trigger with workflow_dispatch in the same on: block is standard practice here, since waiting up to twelve hours to test a schedule change is painful — the manual trigger gives you an on-demand escape hatch.
GitHub-Specific Notes
- →Both fire times — midnight and noon UTC — are maximal-congestion slots (hour boundary plus, for 00:00, the day boundary), so this schedule sees above-average start delays at both ticks.
- →If either tick is skipped under load, the next opportunity is twelve hours away; jobs at this cadence should be written to cover a 24-hour window of work rather than exactly half a day.
- →The expression cannot be shifted with */12 alone; for runs at, say, 05:00 and 17:00 UTC use the explicit list 0 5,17 * * *.
Frequently Asked Questions
How do I test this workflow without waiting up to 12 hours?
Add workflow_dispatch alongside schedule in the on: block and trigger it manually from the Actions tab or via the REST API. The schedule continues to work independently.
Why did only one of my two daily runs happen?
Scheduled delivery is best-effort and both of this schedule's slots are busy ones. A skipped tick is not retried — design the job so a single run can catch up on a missed window.