Every 3 Minutes Cron Expression
Runs at minutes 0, 3, 6, 9, … of every hour.
*/3 * * * * in POSIX cron
Expression
*/3 * * * *Try it in the tester →Field Breakdown
How It Works
Step value `*/3` in the minute field — fires whenever the minute is divisible by 3, 20 times per hour.
Example Run Times
- 12:00:00
- 12:03:00
- 12:06:00
- 12:09:00
- 12:12:00
Frequently Asked Questions
How many times does this run per day?
480 times — 20 fires per hour × 24 hours. Note that minute 60 never matches, so the cadence resets at the top of every hour.
*/3 * * * * in Quartz / Spring
Twenty firings an hour, 480 a day, on every minute divisible by three: :00, :03, :06, up through :57. Because 60 divides evenly by 3, the cadence stays perfectly uniform across the hour boundary — :57 to the next :00 is the same three-minute gap as any other.
Quartz / Spring expression
0 */3 * * * ?Try it in the tester →At second 0, every 3 minutes, every hour
Unix / POSIX equivalent: */3 * * * *
Field Breakdown
Using It with Quartz / Spring
Three minutes is tight-polling territory: chasing payment-provider status when webhooks aren't offered, draining a lightweight outbox, or watching a hot directory for partner file drops. Spring takes it via @Scheduled(cron = "0 */3 * * * ?"); Quartz proper via CronScheduleBuilder. At 480 daily executions the job body's runtime budget matters — anything that can't reliably finish inside three minutes will have a second instance start while the first is still going, unless concurrency is explicitly forbidden on the job.
Quartz-Specific Notes
- →*/3 expands to the twenty-element minute list 0,3,6,...,57; because the step divides 60 exactly, there is no short gap at the top of the hour the way there is with steps like 45.
- →Every firing lands on second 0 — useful when downstream systems bucket events into whole minutes.
- →In a clustered Quartz deployment with a JDBC JobStore, 480 firings a day means 480 trigger-acquisition round trips against the store per trigger; cheap individually, worth counting if dozens of triggers run this hot.
Frequently Asked Questions
What happens when one run takes five minutes?
By default the next scheduled firing proceeds on time, so two executions overlap. Mark the Quartz job class @DisallowConcurrentExecution (or guard with your own lock in Spring) if the work must be serialized.
Can I restrict the three-minute polling to overnight hours?
Constrain the hour field: 0 */3 0-5 * * ? fires every three minutes from 00:00 through 05:57 and stays silent the rest of the day — 120 runs instead of 480.
Does the schedule start three minutes after my app boots?
No — fire times are wall-clock aligned. An app that finishes startup at 10:01:30 first fires at 10:03:00, then every divisible-by-three minute after that.
*/3 * * * * in AWS EventBridge
Sixty divides evenly by three, so */3 in the minute field produces a perfectly regular tick: minutes :00, :03, :06 through :57, 20 times an hour and 480 times a day. This sits between the popular 1- and 5-minute cadences for polling that needs to feel prompt without being constant.
AWS EventBridge expression
cron(*/3 * * * ? *)Try it in the tester →Every 3 minutes UTC
Unix / POSIX equivalent: */3 * * * *
Field Breakdown
Using It with AWS EventBridge
Three-minute rules tend to guard freshness: polling an SFTP drop for new files, checking a third-party API whose webhook support is unreliable, sweeping a DynamoDB table for records whose visibility timeout has lapsed, or nudging a consumer that drains a backlog queue. Attach the expression to a rule and target a Lambda, or target SQS when you want the ticks buffered rather than executed immediately. At 480 invocations a day a misbehaving target gets expensive quickly, so set a concurrency cap or an alarm on the error rate before turning it on.
AWS-Specific Notes
- →480 daily firings compound to roughly 14,600 invocations per month from this single rule — relevant when the target is billed per request.
- →Because 60 is divisible by 3, the gap is a uniform three minutes even across the top of the hour; steps that do not divide 60 lose that property.
- →A three-minute poll whose work occasionally exceeds three minutes will overlap itself — EventBridge fires on schedule regardless of whether the previous invocation finished.
Frequently Asked Questions
Is rate(3 minutes) interchangeable with this cron form?
Functionally close but not identical: the cron version locks runs to clock minutes divisible by three, while rate counts three-minute intervals from when the schedule was enabled, so its firing minutes are arbitrary. Choose cron when you care which minutes, rate when you only care about the interval.
My target sometimes runs twice within the same three-minute slot — why?
EventBridge's delivery guarantee is at-least-once, and under load an invocation may also slide up to a minute late, occasionally bunching two runs together. Make the handler idempotent, for example by deduplicating on the event's time field.
*/3 * * * * in GitHub Actions
The */3 step requests a run at every UTC minute divisible by 3 — twenty per hour, 480 per day. That is well below GitHub Actions' documented 5-minute minimum interval, so this expression asks for more than the platform commits to deliver.
GitHub Actions expression
*/3 * * * *Try it in the tester →Every 3 minutes UTC
Unix / POSIX equivalent: */3 * * * *
Field Breakdown
Using It with GitHub Actions
The YAML on: schedule: - cron: "*/3 * * * *" saves and parses without complaint, which is the trap: GitHub documents five minutes as the shortest supported interval and says nothing about how denser expressions behave, so whatever runs you observe are not a contract. If three-minute polling is a genuine requirement, restructure: schedule a workflow every 15 minutes and have its job loop five times with sleep 180 between iterations, or drive the cadence from an external scheduler that calls the repository_dispatch API. Both give you the rhythm from a supported primitive.
GitHub-Specific Notes
- →Five minutes is the documented floor for the schedule event; the behavior of a */3 expression is simply undocumented — do not assume it rounds, clamps, or falls back to anything in particular.
- →Even taken at face value the math overcommits: 480 requested runs per day against a documented maximum of 288 at the 5-minute floor — the expression promises two-thirds more than the platform's own ceiling.
- →A job built for near-floor frequency must tolerate irregular spacing in any case; if precise sub-5-minute timing matters, GitHub-hosted scheduling is the wrong layer entirely.
Frequently Asked Questions
Is */3 * * * * valid in a GitHub Actions workflow?
Syntactically yes — the file saves and the cron parses. Operationally it requests an interval below the documented 5-minute minimum, and GitHub does not document what happens then. Treat it as unsupported rather than as a slightly-degraded 3-minute schedule.
What is the closest supported alternative to every 3 minutes?
"*/5 * * * *" is the densest documented schedule at 288 runs per day. To genuinely act every 3 minutes, run a 15-minute schedule whose job performs five iterations with a 180-second sleep between them, or fire repository_dispatch from an external clock.