Cron Atlas

Cron expression for every minute

* * * * *
minuteevery minute
hourevery hour
day of monthevery day
monthevery month
day of weekany weekday

Every minute.

Next 10 runs

In Cron, worked out in your browser from the current time.

At a glance

Runs
1,440 a day
Gap between runs
Always 1 minute
Expressible in
All six dialects
Clock changes
Affected in New York, London, Berlin, Helsinki, Sydney

Open in the tester

In each dialect

Every expression here is generated by the tester’s own engine and checked run for run against the others, so “Exact” means the same clock times in the same zone. Each one links to the tester.

* * * * * /path/to/command
Exact
aws events put-rule --name every-minute --schedule-expression "cron(* * * * ? *)"
  • Wrap it in cron(…). Day of week is ? because day of month already holds *, and a * in both is rejected. The final * is the required year field.
  • rate(1 minute) is the interval alternative. It counts from when the rule is created, so runs will not line up with the clock the way the cron form does.
Exact
CronScheduleBuilder.cronSchedule("0 * * * * ?")
  • The leading 0 is the seconds field, so it fires at the top of the minute. Day of week is ? because day of month already holds *, and a * in both is rejected. The optional year is left off.
Exact
schedule: "* * * * *"
  • If a Job can run longer than 1 minute, the next one starts alongside it by default. concurrencyPolicy: Forbid skips the new run instead, and Replace stops the old one.
  • The controller stops starting a CronJob that has missed more than 100 schedules. At this rate that is 1 hour 40 minutes of downtime. startingDeadlineSeconds limits how far back it counts.
Exact
- cron: '* * * * *'
  • This matches every minute, but GitHub’s shortest interval is once every 5 minutes. Real runs will be less frequent than the list below.
  • GitHub warns that schedules can be delayed at high load, which includes the start of every hour, and that some queued jobs may be dropped. A different minute reduces the risk.

For anything more frequent, trigger the workflow from another scheduler through workflow_dispatch or repository_dispatch.

Every 5 minutes at best
[TimerTrigger("0 * * * * *")]
  • Six fields with seconds first, so the leading 0 fires at the top of the minute.
Exact

About this schedule

The finest schedule five-field cron can express. Every field is *, so it matches every minute of every hour of every day. For anything faster you need a seconds field, which only Quartz and Azure have.

Clock changes

Worked out by running each dialect’s engine through New York’s clock changes; it is affected in London, Berlin, Helsinki, Sydney too, at their own local hours.

DialectClocks go forward (02:00 becomes 03:00)Clocks go back (02:00 becomes 01:00)
CronThe 60 runs in the missing hour don’t happenRuns through both passes of the repeated hour: 60 extra runs
EventBridge SchedulerThe 60 runs in the missing hour don’t happenRuns once through the repeated hour
QuartzThe 60 runs in the missing hour don’t happenRuns once through the repeated hour
KubernetesThe 60 runs in the missing hour don’t happenRuns through both passes of the repeated hour: 60 extra runs
GitHubGitHub moves the 60 runs in the missing hour to 03:00, where they are counted once with the 03:00 runGitHub doesn’t document whether the repeated hour runs twice; shown once here
AzureThe 60 runs in the missing hour don’t happenRuns through both passes of the repeated hour: 60 extra runs

Cron follows the crontab man page; daemons differ, and cronie catches up skipped fixed-time jobs. EventBridge applies to Scheduler with a time zone; scheduled rules run in UTC and never see a clock change. Quartz is exact for 2.5.2. GitHub documents the forward case only.

Questions

What is the cron expression for every minute?
* * * * * in standard cron, Kubernetes and GitHub Actions. The other dialects differ: * * * * ? * in EventBridge; 0 * * * * ? in Quartz; 0 * * * * * in Azure.
Does * * * * * count from when the job is created?
No. It matches clock times: 00:00, 00:01, 00:02 and so on, whenever it was created. EventBridge’s rate() form is the one that counts from creation instead.
Will GitHub Actions really run every minute?
No. GitHub accepts the expression, but its shortest interval is once every 5 minutes, and scheduled runs can be delayed at busy times or dropped. Expect runs at most every 5 minutes, sometimes later.
What happens to this schedule when the clocks change?
It depends on the scheduler. When clocks go forward in New York (02:00 becomes 03:00): Cron, EventBridge, Quartz, Kubernetes and Azure: the 60 runs in the missing hour don’t happen. GitHub moves the 60 runs in the missing hour to 03:00, where they are counted once with the 03:00 run. The table on this page also covers the autumn change.

More schedules