* * * * *Fields
| Minute | * | any |
|---|---|---|
| Hour | * | any |
| Day of month | * | any |
| Month | * | any |
| Day of week | * | any |
Where to use it
| crontab | * * * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "* * * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "* * * * *" |
crontab runs in the server’s time zone; GitHub Actions always uses UTC.
Good to know
Every minute is the finest resolution standard cron offers; for anything faster, use a loop inside the script, a second entry starting with sleep 30, or a systemd timer. The main pitfall is overlap: if a run takes longer than a minute, copies pile up. Wrap the job in flock, for example flock -n /tmp/job.lock /path/to/script.sh, so a new run exits while the previous one is still going.
Cron runs with a minimal environment: PATH is usually just /usr/bin:/bin, no shell profile is loaded, and the working folder is your home, so use absolute paths. Output is mailed to the user or discarded, so redirect it with >> /var/log/job.log 2>&1 and rotate that log. GitHub Actions won’t run this often: its shortest interval is 5 minutes. A gentler neighbour is */2, every two minutes.