Cron: Every Minute
A cron expression of * * * * * fires once every minute, all day, every day — the wildcard * in each of the five fields means "any value." It's the highest-frequency schedule standard cron supports (without a seconds field), and it's mostly used for polling, health checks, or queue workers that need near-real-time responsiveness.
* * * * *
Examples & Variations
Common Mistakes
- Running heavy jobs every minute without a lock — if one run takes longer than a minute, the next invocation can overlap it and cause race conditions.
- Forgetting that most CI/CD schedulers (GitHub Actions, GitLab CI) impose a minimum interval — GitHub Actions rounds sub-5-minute schedules up and can delay them further under load.
- Using * * * * * in production for anything expensive; it's almost always cheaper to use a proper queue or a longer interval like */5.
Best Practices
- Add a mutex or lock file so overlapping runs skip instead of stacking up.
- Log start/end timestamps so you can detect a job that's silently taking longer than its interval.
- If you only need per-minute precision during certain hours, restrict the hour field (e.g. * 9-17 * * *) to cut load outside that window.
Frequently Asked Questions
- Is running a cron job every minute bad practice?
- Not inherently — it's standard for health checks and lightweight polling. It becomes a problem when the job itself is slow or resource-intensive, since minute-level cron has almost no room for a run to take longer than 60 seconds without overlapping the next one.
- Can cron run more often than every minute?
- Standard 5-field cron cannot go below one-minute resolution. Some schedulers (Quartz, systemd timers) support a 6-field format with a leading seconds field for sub-minute precision.
- Does every-minute cron work the same in Kubernetes CronJobs?
- Yes — Kubernetes CronJobs use standard 5-field cron syntax, so * * * * * is valid, though Kubernetes itself has scheduling latency and isn't guaranteed to fire at the exact second.