tooloora

Cron every minute — * * * * * explained

What * * * * * really does, when a per-minute job is justified, and how to keep two runs from colliding.

Runs locally — nothing is uploaded

Examples

In plain words

Every minute, every day.

Field by field

  • *Minute

    every minute

    Matches: 0, 1, 2, 3, 4, 5 … 59

  • *Hour

    every hour

    Matches: 0, 1, 2, 3, 4, 5 … 23

  • *Day of month

    on every day of the month

    Matches: 1, 2, 3, 4, 5, 6 … 31

  • *Month

    in every month

    Matches: Jan, Feb, Mar, Apr, May, Jun … Dec

  • *Day of week

    on every weekday

    Matches: Sun, Mon, Tue, Wed, Thu, Fri, Sat

Next runs

Calculating the next runs …

These times apply in the time zone configured on the server. Cron converts nothing; this preview uses your device clock.

The expression stays in your browser — it is never sent to a server.

Other expressions

* * * * * runs the job every minute, around the clock, on every day of the year. All five fields are stars, which cron reads as “every value”. That adds up to 1,440 runs per day, so check first that your job reliably finishes in well under a minute.

How often does * * * * * actually run?

Sixty times an hour, 1,440 times a day. One minute is also the finest resolution classic cron offers: there is no seconds field, so anything faster needs a systemd timer, a supervised daemon or a sleep loop inside your script. The first run happens at the next full minute after you save the crontab.

What happens if a run takes longer than a minute?

Cron does not wait. The next run starts on schedule even while the previous one is still working, so a script that needs two minutes ends up with two copies running permanently. On a busy server that grows into a pile of stuck processes within hours. The usual guard is a lock: start the command with flock -n on a lock file, and the second start exits immediately.

When is a per-minute schedule the right choice?

Rarely. It fits short local checks: draining a queue, writing a heartbeat, watching a file for changes. Anything that calls a third-party API belongs on a longer interval, because 1,440 requests a day run into rate limits fast. And if what you really mean is “react as soon as possible”, a long-running worker with a queue beats any cron schedule.

How to add the expression

  1. Open your crontab with crontab -e (the file belongs to the user whose rights the job needs).
  2. Add the line * * * * * /pfad/zum/skript.sh and save it.
  3. Wrap the command in flock -n /tmp/meinjob.lock so a slow run cannot overlap the next one.
  4. Watch the first few runs in the log before you leave the job alone.

Frequently asked questions

Can cron run a job every 30 seconds?

Not directly: the smallest unit in a crontab is one minute. The common workarounds are two entries where the second one starts with sleep 30, or a systemd timer with OnUnitActiveSec=30s. For anything below that, a permanently running service is the honest answer.

Does * * * * * also run at night and on weekends?

Yes. All five fields are stars, so no hour, day, month or weekday is excluded. If you need quiet hours, restrict the hour field, for example * 6-22 * * * for a job that only runs between 6 a.m. and 10:59 p.m.

Why do I suddenly have dozens of processes?

Almost always overlapping runs: the job needs longer than a minute, and cron keeps starting new copies regardless. Add a lock with flock -n, or make the script exit early when a previous instance is still alive.

Does this explainer send my expression to a server?

No. Parsing, the plain-language description and the list of next runs are all computed in your browser; the expression never leaves your device and the page keeps working offline. Crontab lines often contain paths, hostnames and tokens, so keeping them local is the safer default.