cronuru
Pattern

Every Minute

* * * * *
0 * * * * ?
* * * * *
* * * * ? *
0 * * * * *

Runs every minute — :00, :01, :02, …, :59 of every hour, every day. The highest frequency standard cron supports.

Use in your stack

# Run every minute
* * * * * /usr/local/bin/heartbeat.sh

{ "cron": "0 * * * * ?", "timezone": "UTC" }

apiVersion: batch/v1
kind: CronJob
metadata:
  name: heartbeat
spec:
  schedule: "* * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: heartbeat
            image: my-image:latest
          restartPolicy: OnFailure

cron(* * * * ? *)

@Scheduled(cron = "0 * * * * *")
public void everyMinute() { /* ... */ }

Next runs

Pick a timezone to see when this expression fires next.

Next 10 runs
  1. 012026-07-03T16:51:00.000Z
  2. 022026-07-03T16:52:00.000Z
  3. 032026-07-03T16:53:00.000Z
  4. 042026-07-03T16:54:00.000Z
  5. 052026-07-03T16:55:00.000Z
  6. 062026-07-03T16:56:00.000Z
  7. 072026-07-03T16:57:00.000Z
  8. 082026-07-03T16:58:00.000Z
  9. 092026-07-03T16:59:00.000Z
  10. 102026-07-03T17:00:00.000Z

Variations

*/2 * * * *

Every 2 minutes

 */5 * * * *

Every 5 minutes

 */10 * * * *

Every 10 minutes

 */15 * * * *

Every 15 minutes

Common use cases

  • Heartbeat checks that confirm a service is still alive.
  • High-frequency queue workers that drain pending jobs.
  • Real-time-ish polling where a 1-minute lag is acceptable.
  • Development cron jobs you want to test quickly.

Gotchas

  • 60 invocations per hour, 1440 per day — log volume and observability cost adds up fast.
  • Highest overlap risk of any schedule: if your job takes >1 minute, you'll spawn overlapping instances unless you guard with `flock` or `concurrencyPolicy: Forbid`.
  • GitHub Actions does NOT support `* * * * *` — minimum interval is 5 minutes.
  • AWS EventBridge minimum is 1 minute and requires the 6-field form: `* * * * ? *`.

* * * * * is the simplest cron expression — five asterisks meaning “no restriction on any field.” Read it as “every minute of every hour, every day of the month, every month, every day of the week.” It fires 60 times per hour and 1440 times per day.

This is the fastest schedule standard Unix cron supports. If you need sub-minute precision (every 30 seconds, every 10 seconds), cron is the wrong tool — use systemd timers with OnUnitActiveSec=, a long-lived process with an in-memory scheduler, or a queue like Celery Beat.

Frequently asked questions

What does `* * * * *` mean?
All five asterisks mean "every valid value for this field." In order, the fields are minute, hour, day of month, month, and day of week. So `* * * * *` reads as "every minute of every hour of every day of every month, every day of the week" — the most frequent schedule possible in standard cron.
Can GitHub Actions run a workflow every minute?
No. GitHub Actions enforces a minimum schedule interval of 5 minutes. The fastest valid expression on GitHub Actions is `*/5 * * * *`. If you need every-minute precision, run a long-lived service (Cloudflare Worker cron, AWS Lambda + EventBridge, Render cron) instead of GitHub Actions.
What's the minimum interval for AWS EventBridge cron?
1 minute. EventBridge schedule expressions require 6 fields (including year): `cron(* * * * ? *)`. Expressions are always evaluated in UTC.
Why is every-minute cron risky?
Three reasons. First, 1440 invocations per day produces a lot of logs and metrics. Second, if a job takes longer than 60 seconds, the next run starts while the previous is still going — you can pile up overlapping instances and exhaust resources. Third, every minor failure becomes hundreds of failures in a day. Guard with locks (`flock`, `concurrencyPolicy: Forbid`), set timeouts, and back off on errors.

Browse all cron patterns

Every schedule Cronuru documents, with its expression and code snippets for six dialects.

Seconds

Minutes

Hours

Daily

Weekly

Calendar