Cron Jobs Every Minute: Syntax, Risks & Monitoring

Running cron jobs every minute is easy to set up and surprisingly easy to break. The syntax takes seconds to write; the operational fallout — overlapping executions, log floods, alert fatigue — shows up weeks later when nobody's watching. This guide gives you the exact crontab line, the hard limits of cron's scheduler, and the monitoring approach you need once a job is firing 1,440 times a day.

The Exact Crontab Syntax to Run a Job Every Minute

Open your crontab with crontab -e and add:

* * * * * /path/to/your/script.sh

Every field is a wildcard, so cron evaluates the job every minute of every hour, every day, every month, on every weekday. That's the cron every minute syntax in its entirety — no special flags, no extra configuration.

You'll also see */1 * * * * /path/to/your/script.sh in tutorials. The */1 * * * * pattern means "every 1st minute," functionally identical to * * * * *. The step syntax (*/N) matters when N is greater than 1 — */5 * * * * for every five minutes — but at N=1 it just reduces to the plain wildcard. Use whichever reads more clearly; cron treats them the same way.

The crontab field order is always minute, hour, day-of-month, month, day-of-week. When all five are *, the daemon (cron or crond, depending on distribution) checks the schedule and dispatches the job once per minute, indefinitely.

Why Cron Has a Hard 60-Second Floor

Cron's scheduler resolution is one minute — a structural limit, not a configuration setting. It wakes up once every 60 seconds, checks the crontab entries, and fires anything that matches. No field combination pushes it below that; you cannot run cron every 30 seconds with crontab fields alone.

If you genuinely need sub-minute scheduling, three common workarounds exist:

• Duplicate crontab lines with a sleep offset — one line runs the job immediately, a second runs sleep 30 && /path/to/script.sh for a 30-second cadence. Crude, but it works without new tooling.
• systemd timers — Linux's systemd offers timer units with finer-grained scheduling and better logging than cron, a more robust choice if you're already systemd-based.
• An application-level loop — a long-running process that sleeps and re-executes internally, bypassing the OS scheduler entirely.

Each trades cron's simplicity for more moving parts, so reach for them only when a genuine sub-minute requirement exists — not because "faster is safer."

The Hidden Risk: Overlapping Executions

This is the risk most "run cron every minute" tutorials skip, and the one that actually causes incidents. Cron doesn't check whether the previous run finished before starting the next. If your script normally completes in 20 seconds but occasionally takes 90 — a slow API, a database lock, unusual load — cron will start a second instance while the first is still running.

Repeat that pattern and you get overlapping jobs: multiple instances competing for the same file, database rows, or API rate limit — a textbook race condition. Failure modes range from duplicate records and corrupted writes to a slow spiral where each overlapping instance adds load, making every subsequent run even slower.

The standard mitigation is a lock file combined with flock:

* * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/script.sh

flock -n tries to acquire an exclusive lock on /tmp/myjob.lock and exits immediately if another instance already holds it, instead of running concurrently. This doesn't fix a job that's genuinely too slow for its interval — that's a performance problem — but it stops overlap from compounding into something worse. For a deeper look at how silent failures like this go undetected, see Crontab Monitoring: How to Catch Silent Cron Failures.

Server Load and Log Noise at 1,440 Runs a Day

A job that runs once an hour barely registers. A job that runs every minute produces 1,440 executions daily, and each one leaves a footprint — a shell fork, a process start, output written to /var/log/cron or forwarded via mail if MAILTO is set, plus whatever CPU/IO the script consumes.

None of that is catastrophic alone. The real cost is compounding noise: a script logging a few lines per run generates thousands of lines a day, cron's mail delivery can flood an inbox if output isn't suppressed, and if the task touches disk or network, you're now doing that 1,440 times instead of 24. High-frequency cron load rarely crashes a server outright — it erodes visibility. Teams stop reading logs because there's too much of them, which is exactly when a real failure slips through unnoticed.

This is the point where raw log-watching stops being viable, and where teams start looking for purpose-built tooling. Cron Monitor: What It Is and How to Choose One walks through what to look for.

Monitoring an Every-Minute Cron Job the Right Way

Standard cron monitoring ("did the job run today?") is nearly useless at this frequency — of course it ran, 1,440 times. The question that matters is which runs failed, which ran slow enough to risk overlap, and whether any actually skipped.

A job that appears to "skip a run" is almost always an overlap collision (the previous instance was still holding a lock or resource) or a system-clock/load hiccup delaying the scheduler's wake-up by a few seconds. Either way, you need per-run visibility to tell the difference, not a daily summary.

Effective monitoring for cron every minute needs four things:

• Per-run execution history — success/failure logged for every single run, not a daily rollup.
• Duration trend tracking — so a job creeping from 20 seconds toward the 60-second ceiling is flagged before it starts overlapping.
• Overlap detection — an explicit signal when a new run starts before the previous one reports completion.
• Grace-period tuning — alert thresholds set for this job's real cadence, so a few seconds of scheduler jitter doesn't page anyone at 3 a.m.

Push-based or heartbeat-style checks fit this pattern well, since the job itself reports "I started" and "I finished" rather than something polling for its existence — see Healthcheck Systems Explained: Pull, Push, and Heartbeat for how that model works. If your real requirement is faster than cron can go, compare dedicated schedulers rather than stacking workarounds — Open Source Job Scheduler: 7 Options Compared for 2025 covers the field.

Once the syntax is right and overlap is handled with a lock, the remaining problem is scale: nobody can manually check 1,440 log entries a day. Cronevra gives every run its own recorded history, tracks duration trends, and flags overlap and failures with alert thresholds tuned for high-frequency jobs instead of generic daily checks. Check the pricing page to see which plan fits your job volume.

Frequently Asked Questions

What is the exact crontab syntax to run a job every minute?

Use * * * * * /path/to/script.sh in your crontab, where all five wildcard fields mean "every minute, every hour, every day." The equivalent step-syntax version, */1 * * * *, behaves identically since a step of 1 matches every value.

Can a cron job run more often than once per minute?

No — cron's daemon has a fixed one-minute scheduling resolution and cannot natively trigger jobs below that interval. Genuine sub-minute needs require a workaround such as duplicate crontab lines with sleep offsets, a systemd timer, or an application-level loop managing its own timing.

Why does my every-minute cron job sometimes seem to skip a run?

It's almost always an overlap collision or scheduler jitter, not an actual skip. If the previous run is still executing when the next one is due — because it took longer than 60 seconds — a lock file or flock will block the new instance, which can look like a missed run without per-run monitoring.

Is running a cron job every minute bad for server performance?

Not inherently, but cumulative load matters more than any single run. At 1,440 executions a day, log volume, mail output, and CPU/IO usage all multiply, and the bigger risk is usually log noise obscuring real failures rather than raw resource exhaustion.

How do I stop an every-minute cron job from overlapping with itself?

Wrap the job with flock -n and a lock file, for example flock -n /tmp/myjob.lock /path/to/script.sh. This makes cron skip starting a new instance if the previous one hasn't released the lock, preventing concurrent execution and the race conditions that come with it.

What's a better alternative to cron for jobs that need to run faster than every minute?

systemd timers or a dedicated job scheduler are generally better fits than stacking cron workarounds. They offer finer scheduling control and better native logging, and it's worth comparing options designed for that use case rather than forcing cron below its 60-second floor.