Every Minute Cron Expression
Runs once every minute, every hour of every day.
* * * * * in POSIX cron
Expression
* * * * *Try it in the tester →Field Breakdown
How It Works
Five wildcards — the job fires at the top of every minute, 1,440 times per day.
Example Run Times
- 12:00:00
- 12:01:00
- 12:02:00
- 12:03:00
- 12:04:00
Frequently Asked Questions
Is `* * * * *` the same as `@every 1m`?
Functionally yes for Unix cron. `@every 1m` is a Go cron extension and is not portable to crontab or POSIX cron.
Will this run on the second boundary?
Standard Unix cron has minute-level resolution. The job is queued at second 0 of each minute. For sub-minute scheduling use Quartz with a seconds field.
* * * * * in Quartz / Spring
Running a Quartz trigger every minute means 1,440 firings per day, each at second 0. It's the densest cron cadence most Java teams ever deploy, and it puts real pressure on thread pools and job runtimes.
Quartz / Spring expression
0 * * * * ?Try it in the tester →At second 0, every minute, every hour
Unix / POSIX equivalent: * * * * *
Field Breakdown
Using It with Quartz / Spring
Wire it up with TriggerBuilder.newTrigger().withSchedule(CronScheduleBuilder.cronSchedule("0 * * * * ?")) in plain Quartz, or annotate a Spring bean method with @Scheduled(cron = "0 * * * * ?"). Typical one-minute jobs are heartbeat writers, distributed-lock renewals, and pollers watching a database table or directory for new work. At this frequency the job body must reliably finish well under 60 seconds, or executions start stacking up in the scheduler's thread pool.
Quartz-Specific Notes
- →If an execution runs longer than a minute, Quartz will happily start the next one in parallel — annotate the job class with @DisallowConcurrentExecution to serialize runs.
- →Spring's default TaskScheduler is single-threaded, so a slow minute job silently delays every other @Scheduled method in the application.
- →After downtime, the default misfire handling (smart policy resolves to FIRE_ONCE_NOW for CronTrigger) collapses all missed minutes into a single catch-up firing.
Frequently Asked Questions
Can Quartz fire more often than once a minute?
Yes — that's what the seconds field is for. 0/15 * * * * ? fires every 15 seconds, something plain Unix cron cannot express at all.
Is an every-minute cron job expensive in Quartz?
The trigger itself is cheap; the cost is in your job. With a JDBC JobStore each firing also touches the database for trigger state, so 1,440 daily firings add measurable load in clustered setups.
Why six fields when crontab only needs five?
Quartz prepends a seconds field and requires a ? in either day-of-month or day-of-week. The Unix * * * * * becomes 0 * * * * ? — same wall-clock behavior, different grammar.
* * * * * in AWS EventBridge
One minute is the floor for EventBridge scheduling — this expression runs your target as often as the service allows, 1,440 times per day. The six fields inside the cron() wrapper are minute, hour, day-of-month, month, day-of-week, and year, with the day-of-week set to ? because day-of-month is already a wildcard.
AWS EventBridge expression
cron(* * * * ? *)Try it in the tester →Every minute UTC
Unix / POSIX equivalent: * * * * *
Field Breakdown
Using It with AWS EventBridge
Pass this string as the ScheduleExpression in a PutRule call, an AWS::Events::Rule resource in CloudFormation, or a CreateSchedule call on the newer EventBridge Scheduler. Per-minute rules typically drive heartbeat Lambdas, SQS queue-depth checks, or watchdogs that verify another system is still alive. At this frequency many teams skip cron entirely and write rate(1 minute), which is equivalent and easier to read.
AWS-Specific Notes
- →EventBridge cannot schedule anything more frequent than once per minute, so this is the maximum possible cadence.
- →Exactly one of day-of-month and day-of-week must be ? — here day-of-week carries it because day-of-month is *.
- →Delivery is at-least-once and rules can fire up to a minute late under load, so a per-minute target must tolerate the occasional duplicate or back-to-back invocation.
- →A Lambda target invoked 1,440 times a day accrues roughly 43,800 invocations per month from this one rule — worth checking against your budget before enabling it.
Frequently Asked Questions
Should I use cron(* * * * ? *) or rate(1 minute)?
They fire at the same frequency. rate(1 minute) is the idiomatic choice for plain fixed intervals; reach for cron only when you later need to restrict the window, for example minutes only during business hours.
Can EventBridge run something every 30 seconds?
No. One minute is the minimum granularity for both rules and the Scheduler. For sub-minute work, have the per-minute invocation loop internally or use Step Functions with Wait states.
Why does my per-minute rule sometimes skip or double a minute?
EventBridge guarantees at-least-once delivery, not exactly-once, and invocations can lag up to a minute when the service is busy. Design the target to be idempotent.
* * * * * in GitHub Actions
Five wildcards is the densest schedule cron can express — 1,440 fire times per day — but GitHub Actions will not honor it. The platform's documented floor is one run every 5 minutes, so this expression is effectively an invalid request even though the syntax parses.
GitHub Actions expression
* * * * *Try it in the tester →Every minute UTC
Unix / POSIX equivalent: * * * * *
Field Breakdown
Using It with GitHub Actions
You would place this string under on: schedule: - cron: "* * * * *" in a workflow YAML file, quoted because the asterisks are YAML-significant. GitHub documents 5 minutes as the shortest schedulable interval, and the behavior of denser expressions is undocumented — observed runs are irregular rather than any clean fallback cadence. Teams that genuinely need per-minute execution move the loop inside a single long-running job, use repository_dispatch triggered by an external scheduler, or run a self-hosted poller. Keep this pattern for crontab on a Linux box; on Actions it signals a design problem.
GitHub-Specific Notes
- →GitHub Actions enforces a 5-minute minimum interval — a workflow with * * * * * will not actually run every minute.
- →Even at the supported floor, delivery is best-effort: queue pressure routinely delays scheduled runs by several minutes, which makes sub-5-minute precision impossible by design.
- →Each scheduled run consumes billable Actions minutes on private repos, so dense schedules burn quota fast even when most runs are no-ops.
Frequently Asked Questions
Can a GitHub Actions workflow run every minute?
No. The shortest supported schedule interval is 5 minutes. To react faster than that, trigger the workflow externally with repository_dispatch or the workflow_dispatch API from a system that can fire per minute.
What happens if I commit * * * * * anyway?
The workflow file is accepted, but runs will not occur every minute — 5 minutes is the documented minimum, and what a denser expression actually does is undocumented. Don't rely on any particular fallback cadence.