What is the cron expression for every minute?

The cron expression for every minute is "* * * * *". Runs once every minute, all day, every day.

What should I watch out for when running a cron job every minute?

Overlap is the killer. If one run takes longer than 60 seconds, the next starts anyway and they stack until the box runs out of memory. Wrap the command in flock -n /tmp/job.lock so a late run skips instead of piling up. 1,440 runs a day floods logs and cron mail. Redirect output (>/dev/null 2>&1) and log only failures, or your real errors drown.

Cron expression for Every minute

* * * * *

Runs once every minute, all day, every day.

Next 5 runs (your local time)

These are shown in your browser’s timezone. The job itself runs in the scheduler’s timezone — often UTC — so the real run time can differ.

What people actually schedule with `* * * * *`

Polling a job queue or inbox for near-real-time processing when the upstream system has no webhooks
Refreshing a leaderboard or live counter that users expect to feel “live”
Watching a directory for uploaded files that must be picked up quickly

Use `* * * * *` on your platform

It’s the same 5-field expression everywhere — what changes is where you put it and which timezone it runs in.

Linux / crontab

* * * * * /path/to/your-command

Runs in the server’s local timezone — check it with timedatectl. Full field reference: crontab(5) man page.

GitHub Actions

on:
  schedule:
    - cron: "* * * * *"

GitHub Actions always runs scheduled jobs in UTC — there is no timezone setting, and runs can be delayed under load (official docs).

Kubernetes CronJob

spec:
  schedule: "* * * * *"

Defaults to UTC. Set spec.timeZone (Kubernetes 1.27+) for a specific zone — see the CronJob docs.

Quartz / Spring `@Scheduled`

Quartz uses 6 fields (seconds first): 0 * * * * *. Watch out: Quartz day-of-week is 1=SUN … 7=SAT (not 0–6), and day-of-month / day-of-week use ? — double-check if your schedule touches those fields (Quartz cron reference).

Gotchas with every minute schedules

Overlap is the killer. If one run takes longer than 60 seconds, the next starts anyway and they stack until the box runs out of memory. Wrap the command in flock -n /tmp/job.lock so a late run skips instead of piling up.
1,440 runs a day floods logs and cron mail. Redirect output (>/dev/null 2>&1) and log only failures, or your real errors drown.
Managed schedulers quietly won’t honor it: GitHub Actions’ effective minimum is ~5 minutes and runs are delayed under load — every-minute cron there is a polite fiction.

Will you know if this job silently fails?

Cron jobs fail quietly — a server reboots, a path changes, or an error code is ignored — and nobody notices until the data is missing. A cron monitor (a dead-man’s-switch) alerts you when a scheduled job does not check in on time.

Monitor your cron jobs with UptimeRobot →

Disclosure: this is an affiliate link — we may earn a commission if you sign up, at no extra cost to you.

Is `* * * * *` the right schedule?

If you’re only polling an API, every 5 minutes cuts your calls 5× and nobody notices. If you genuinely need sub-minute reaction, cron is the wrong tool — use a webhook, a queue consumer, or a daemon.

Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule: