Cron Every Minute
Five stars run a job at the start of every minute, all day, every day. Here it is in every scheduler, with the next runs in your time zone.
minute · hour · day · month · weekday
Build it with controlsEvery 1 min
The last hour counts in full: the last run each day is at 11:59 PM.
In plain English
Every minute.
Tap a field to see what it means.
- Next run
- —
- Usually every
- —
- Time zone
- Yours
Convert to another schedulerQuartz, Spring, AWS, GitHub Actions, Kubernetes
| Standard cron | * * * * * | current |
|---|---|---|
| Quartz | 0 * * * * ? | |
| Spring | 0 * * * * * | |
| AWS EventBridge | cron(* * * * ? *) | |
| GitHub Actions | * * * * * | |
| Kubernetes | * * * * * |
About Standard cronTime zone, day numbering, daylight saving
- Runs in the machine’s local time zone; cronie also reads CRON_TZ at the top of the crontab.
- Five fields, then the command. Day of week is 0–7 (0 and 7 are Sunday) or SUN–SAT; months 1–12 or JAN–DEC.
- When both day fields are set, a day that matches either one runs.
- Daylight saving: a job at a fixed time in a skipped hour runs right after the change, and one in a repeated hour runs once. Jobs with * in the minute or hour follow the clock.
Sources: crontab(5), cronie, cron(8), cronie, POSIX crontab.
How this works: Method, 10 sources, Checked against 1 worked example,
How this works
Method
The expression is read field by field with the rules of the scheduler you pick (ranges, lists, steps, names, @ macros, and L, W and # where it has them) into the values each field allows. The next runs come from stepping forward through the calendar in the chosen time zone, day by day and then time by time, using that scheduler’s rule for when both day fields are set and its documented rule for daylight saving (where it has none, a skipped time is skipped and a repeated one runs once). A conversion to another scheduler is parsed back and checked against the original before it is shown.
Sources
How it’s tested
One worked example for this page is checked by automated tests before every release: given the inputs, the tool must show the expected answer.
Changes
- First version: plain English and the next runs for six schedulers, a builder, conversion between them, and 20 pages for common schedules.
Worked example: * * * * *
Say the clock reads Monday 4 January 2027, 10:07 AM UTC. * * * * * means “every minute”, so the next five runs are Monday 4 January 2027, 10:08 AM, 10:09 AM, 10:10 AM, 10:11 AM and 10:12 AM.
In UTC, where no clock change interrupts it, that comes to 1,440 runs a day, 10,080 a week and 525,600 in 2027.
How * * * * * works
A cron expression is five fields, read left to right: minute, hour, day of the month, month and day of the week. An asterisk means “any value”, so five of them match every minute of every hour of every day. The cron daemon wakes once a minute, compares the current time with each line of the crontab and starts every job whose fields all match.
Because the smallest field is the minute, this is as often as Linux cron can run anything. The job starts a moment after the start of each minute, 1,440 times a day, and cron starts the next copy on time whether or not the last one has finished.
In schedulers with a seconds field you have to say which second: Quartz writes it 0 * * * * ? and Spring 0 * * * * *. A star in the seconds field there would mean every second, sixty times as often.
Pitfalls
- Overlap: if a run can take longer than a minute, two copies will run at once. On Linux, wrap the command in flock -n with a lock file so a new run gives up while the old one holds the lock; in Kubernetes set concurrencyPolicy: Forbid.
- GitHub Actions won’t run a workflow every minute: its shortest interval is every 5 minutes, and runs at busy times can be late.
- Logs and mail: cron mails any output of every run to the crontab’s owner by default, which is 1,440 messages a day from a chatty script. Redirect the output to a log file.
- cron(8) examines cron entries every minute, so one minute is the finest schedule a standard crontab can express. Source: crontab(5), cronie.
- A Kubernetes CronJob’s default concurrencyPolicy is Allow, so overlapping Jobs run side by side unless you set Forbid or Replace. Source: Kubernetes: CronJob.
“Every Minute” in every scheduler
The same schedule written for each scheduler, converted and checked by this tool. A dash means that scheduler can’t express it in one expression; the note says why.
| Scheduler | Expression | Note |
|---|---|---|
| Standard Unix cron (Vixie cron, cronie) | * * * * * | |
| Quartz Scheduler (Java) | 0 * * * * ? | |
| Spring Framework @Scheduled | 0 * * * * * | |
| Amazon EventBridge cron() | cron(* * * * ? *) | |
| GitHub Actions schedule | * * * * * | |
| Kubernetes CronJob | * * * * * |
Frequently Asked Questions
Does * * * * * run every second?
No. Standard cron has no seconds field, so five stars mean every minute, at the start of the minute. Every second needs a scheduler with seconds, where it is * * * * * * in Spring or * * * * * ? in Quartz.
How do I stop a job that runs every minute from overlapping itself?
Cron doesn’t wait for the last run. On Linux, start the command with flock -n /tmp/myjob.lock so a second copy exits straight away while the first holds the lock. In Kubernetes, set .spec.concurrencyPolicy to Forbid, which skips a run while the previous Job is still going.
Is every minute too often?
For a quick check, such as polling a queue or a health endpoint, it is common. For anything heavy it adds load 1,440 times a day; every 5 or 15 minutes is often enough, and it leaves room for runs that take longer than usual.