Cron expression for every minute

Every minute

*
minute
*
hour
*
day (month)
*
month
*
day (week)

Every minute

Try this expression in the interactive tool:

Open in cron explainer →

Next 10 scheduled runs

#1Thu, 16 Apr 2026, 00:08
#2Thu, 16 Apr 2026, 00:09
#3Thu, 16 Apr 2026, 00:10
#4Thu, 16 Apr 2026, 00:11
#5Thu, 16 Apr 2026, 00:12
#6Thu, 16 Apr 2026, 00:13
#7Thu, 16 Apr 2026, 00:14
#8Thu, 16 Apr 2026, 00:15
#9Thu, 16 Apr 2026, 00:16
#10Thu, 16 Apr 2026, 00:17

Common use cases

The every-minute schedule is the highest-frequency cron pattern available, since standard cron only supports minute-level granularity. It's commonly used during development and debugging to verify that a cron daemon or scheduler is working correctly before switching to a production schedule.

In production, every-minute jobs typically handle lightweight, time-sensitive operations: checking a message queue for new items, polling an external API for webhook-like behaviour when webhooks aren't available, updating a real-time dashboard cache, or rotating short-lived session tokens.

Be cautious with this schedule on resource-constrained systems. If the job takes longer than 60 seconds to complete, a new instance will start before the previous one finishes — leading to overlapping executions. Most implementations guard against this with a lock file or a "skip if already running" check at the start of the script.

Platform-specific syntax

crontab
* * * * * /path/to/script.sh
AWS EventBridge
rate(1 minute)
GitHub Actions
schedule:
  - cron: '* * * * *'  # Runs every minute (UTC)
Kubernetes
schedule: "* * * * *"

Technical breakdown

The expression * * * * * has five fields: minute=*, hour=*, day (month)=*, month=*, day (week)=*. Every minute.

Frequently asked questions

Can cron run more frequently than every minute?
No. Standard cron's smallest unit is one minute. For sub-minute scheduling, use systemd timers (which support seconds), a language-level scheduler like node-cron with second fields, or a simple loop with a sleep interval inside a long-running process.
Will overlapping executions cause problems?
Potentially, yes. If your script takes longer than 60 seconds, the next invocation starts before the previous one finishes. Use a lock file (flock on Linux), a database advisory lock, or check for a running PID at the start of your script to prevent overlap.