Every 5 Minutes Cron Expression
Runs at minutes 0, 5, 10, 15, … of every hour.
*/5 * * * * in POSIX cron
Expression
*/5 * * * *Try it in the tester →Field Breakdown
How It Works
The minute field uses the `*/5` step syntax — it fires whenever the minute is divisible by 5.
Example Run Times
- 12:00:00
- 12:05:00
- 12:10:00
- 12:15:00
- 12:20:00
Frequently Asked Questions
Is `*/5 * * * *` the same as `0,5,10,15,20,25,30,35,40,45,50,55 * * * *`?
Yes — `*/5` is just shorthand for the explicit list. Both fire 12 times per hour at the same minutes.
Does the schedule reset across hour boundaries?
No. The cron daemon evaluates each minute independently against the pattern, so minute 0 of every hour is always a fire point.
*/5 * * * * in Quartz / Spring
Quartz needs six fields, so the familiar */5 minute pattern picks up a leading seconds field: this trigger fires at second 0 of every fifth minute. It's the workhorse schedule for Java polling jobs.
Quartz / Spring expression
0 */5 * * * ?Try it in the tester →At second 0, every 5 minutes, every hour
Unix / POSIX equivalent: */5 * * * *
Field Breakdown
Using It with Quartz / Spring
In Spring, pass this string to @Scheduled(cron = "0 */5 * * * ?") on any bean method, or build a CronTrigger with it in plain Quartz. Five-minute polling is the classic cadence for queue drains, cache refreshes, and outbox relays where a full message broker would be overkill.
Quartz-Specific Notes
- →The leading 0 is the seconds field — omitting it leaves a 5-field expression Quartz rejects outright.
- →The trailing ? means "no specific day-of-week"; Quartz requires ? in exactly one of the two day fields.
- →Fires on clock minutes divisible by 5 (:00, :05, :10…), not every 5 minutes from application startup — use a SimpleTrigger for true fixed intervals.
Frequently Asked Questions
Why does Quartz reject */5 * * * *?
That's the 5-field Unix form. Quartz requires six fields with seconds first — the equivalent is 0 */5 * * * ?.
Does this fire every 5 minutes from when my app starts?
No — it fires on wall-clock minutes divisible by 5. An app started at 10:03 first fires at 10:05. For start-time-relative intervals, use Quartz's SimpleTrigger or Spring's fixedRate instead.
*/5 * * * * in AWS EventBridge
This rule fires at every clock minute divisible by 5 — :00, :05, :10, and so on — for 288 invocations per day. It is probably the single most common polling cadence on EventBridge, frequent enough to feel responsive without hammering downstream APIs.
AWS EventBridge expression
cron(*/5 * * * ? *)Try it in the tester →Every 5 minutes UTC
Unix / POSIX equivalent: */5 * * * *
Field Breakdown
Using It with AWS EventBridge
Set it as the ScheduleExpression on a rule with aws events put-rule, or as the schedule of an EventBridge Scheduler CreateSchedule call, then attach a target such as a Lambda function, an SQS queue, or an ECS RunTask. Five-minute polling suits S3 inventory sweeps, third-party API syncs with rate limits, and reconciliation jobs that drain a DynamoDB outbox table. Terraform users put the same string in aws_cloudwatch_event_rule's schedule_expression argument.
AWS-Specific Notes
- →Runs align to wall-clock five-minute boundaries in UTC, not to five minutes after the rule was created.
- →The ? sits in day-of-week and the trailing * is the mandatory year field — drop it and PutRule returns a ValidationException.
- →rate(5 minutes) produces the same frequency but anchors to creation time rather than to :00/:05 boundaries.
Frequently Asked Questions
Why did AWS reject */5 * * * * as my schedule?
EventBridge needs six fields wrapped in cron(), with a year field at the end and a ? in one of the two day fields. The accepted form is cron(*/5 * * * ? *).
Will all 288 daily runs land exactly on the five-minute mark?
They target the boundary but EventBridge only promises invocation within the minute, and under load a run can arrive up to a minute late. Treat the timestamps as approximate.
*/5 * * * * in GitHub Actions
This is the fastest cadence GitHub Actions officially supports: the */5 step in the minute field requests a run whenever the UTC minute is divisible by 5, up to 288 times per day. You are operating at the platform's documented minimum interval.
GitHub Actions expression
*/5 * * * *Try it in the tester →Every 5 minutes UTC
Unix / POSIX equivalent: */5 * * * *
Field Breakdown
Using It with GitHub Actions
Quote the string in your workflow file as on: schedule: - cron: "*/5 * * * *" — unquoted asterisks can confuse YAML parsers. Teams use this ceiling-speed schedule for upstream-API polling, deployment health probes, and mirroring jobs where a webhook is unavailable. Because every repository asking for maximum frequency competes for the same runner pool, expect this schedule to show the worst delay-to-interval ratio of any cadence on the platform.
GitHub-Specific Notes
- →Five minutes is the documented minimum — expressions denser than that (like */3 or */4) aren't supported, and their actual behavior is undocumented. Use */5 or wider.
- →Scheduled runs are best-effort: a nominal 12:05 slot may start at 12:09 or be skipped entirely during incident-level queue pressure, so jobs at this cadence must tolerate missed ticks.
- →Only the workflow file on the default branch is evaluated; pushing a 5-minute schedule to a feature branch does nothing until it merges.
Frequently Asked Questions
Is */5 * * * * really the fastest GitHub Actions schedule?
Yes. GitHub documents 5 minutes as the shortest interval for the schedule event. Anything denser requires an external trigger such as repository_dispatch.
Why did my 5-minute workflow only run 200 times yesterday instead of 288?
Scheduled delivery is best-effort. Under runner congestion GitHub delays or drops ticks, and high-frequency schedules are affected most. Design the job to catch up on whatever the previous run missed.
Does the 5-minute schedule use my Actions minutes?
On private repositories, yes — every run bills at least the job's execution time against your plan's minutes. 288 daily runs add up quickly, so keep the job short or add an early-exit check.