* * * * *
Every minute
Field by Field
| Field | Value | Matches |
|---|---|---|
| Minute | * | every minute |
| Hour | * | every hour |
| Day of month | * | every day |
| Month | * | every month |
| Day of week | * | every day |
The Schedule With No Slack
A minute is the finest granularity standard cron offers, and it is the schedule most likely to break. There is no gap between runs: if a job takes 70 seconds, the next one starts before the last finishes, and within an hour you have dozens running concurrently.
Take a lock:
``bash
* * * * * /usr/bin/flock -n /tmp/job.lock /opt/app/job.sh
`
flock -n exits immediately rather than queueing, which is what you want — a skipped run
is better than a pile-up.
When a Minute Is the Wrong Tool
Wanting per-minute work usually means wanting a queue. A worker process consuming a queue
reacts in milliseconds, has natural backpressure, and does not spawn 1,440 processes a day.
Reach for cron at this frequency only when the work is genuinely a poll of something you
cannot subscribe to.
Time Zones
Standard crontab evaluates in system local time. Vercel Cron, GitHub Actions, Kubernetes
CronJobs and AWS EventBridge all evaluate in UTC. If converting your local time crosses
midnight, the day-of-week field shifts too — weekdays at 5pm in UTC-07:00 is
0 0 * * 2-6, not 0 0 * * 1-5.
The Day-Field Trap
When both the day-of-month and day-of-week fields are restricted, cron matches either,
not both. 0 0 13 * 5 runs on every 13th *and* every Friday — not Friday the 13th. Leave
one of them as * unless you genuinely want the union.
Other Common Schedules
| Expression | Runs |
|---|---|
* * * * * | Every minute |
*/5 * * * * | Every 5 minutes |
*/15 * * * * | Every 15 minutes |
0 * * * * | Every hour, on the hour |
0 0 * * * | Every day at midnight |
0 9 * * * | Every day at 9am |
0 9 * * 1-5 | Weekdays at 9am |
0 9 * * 1 | Every Monday at 9am |
Making the Job Safe
Assume double firing. DST transitions, restarts and retries all cause it. Make the job
idempotent rather than assuming exactly-once.
- Assume overlap. Cron starts the next run whether or not the last one finished. Take a
lock.
Avoid:00.Every hourly job on the internet fires at the top of the hour; a random
minute spreads load on shared APIs.
- Log the start and end. A cron job that silently stops running is invisible until
someone notices the missing output.Deploying This Schedule
`bash
# crontab -e (system local time)
* * * * * /usr/local/bin/job.sh >> /var/log/job.log 2>&1
`
`json
// vercel.json (UTC)
{ "crons": [{ "path": "/api/job", "schedule": "* * * * *" }] }
`
`yaml
# .github/workflows/job.yml (UTC)
on:
schedule:
- cron: '* * * * *'
`
Starting from midnight UTC on 1 January 2026, this fires at:
| Next runs |
|---|
| 2026-01-01 00:01 UTC |
| 2026-01-01 00:02 UTC |
| 2026-01-01 00:03 UTC |
| 2026-01-01 00:04 UTC |
Every minute.Making It Survive Production
Redirect output. A cron job with no redirect emails its output to the crontab owner,
and on most servers that mail goes nowhere. Log to a file instead.
Use absolute paths. Cron runs with a minimal environment — noPATHyou recognise,
no shell profile, no nvm. A script that works in your terminal frequently fails here
for exactly that reason.
Escape percent signs. In a crontab,%means newline.date +\%Yneeds the
backslash or the command truncates at the percent.
Take a lock. Cron starts the next run whether or not the last finished.flock` is
- Alert on absence. A job that stops running is silent. Ping a dead-man's-switch service