Every Second

Use in your stack

# The sleep-offset trick does not scale here: every second would be
# SIXTY crontab entries. One per-minute entry driving a loop is the
# only sane crontab form.
* * * * * for i in $(seq 60); do /usr/local/bin/tick.sh & sleep 1; done

# But at 1 Hz you want a long-lived process, not a scheduler.
# A systemd service with an internal ticker, or a monotonic timer:
#   /etc/systemd/system/tick.timer
#   [Timer]
#   OnUnitActiveSec=1s
#   AccuracySec=1s          # defaults to 1min — 60x too coarse here
#
# Note OnUnitActiveSec measures from the END of the last run, so a
# slow job stretches the interval instead of stacking invocations.

{
  "schedule": {
    "cron": "* * * * * ?",
    "timezone": "UTC"
  }
}

// 6-field: second minute hour day-of-month month day-of-week
@Scheduled(cron = "* * * * * *")
public void everySecond() {
    // ...
}

// Better at this cadence — waits for the previous run to finish:
@Scheduled(fixedDelay = 1000) // milliseconds
public void everySecondNoOverlap() {
    // ...
}

Next runs

Pick a timezone to see when this expression fires next.

Variations

Common use cases

• Driving a live development dashboard or local debug readout.
• Tailing a high-throughput queue where one second of latency is the budget.
• Emitting a heartbeat or liveness tick to a monitoring system.
• Polling a hardware sensor or serial device on a tight loop.

Gotchas

• **Unix crontab cannot do this.** The 5-field format has no seconds field; its minimum is `* * * * *` (every minute). Kubernetes CronJob, AWS EventBridge and Cloudflare Workers inherit the same one-minute floor, and GitHub Actions floors at five minutes.
• **A systemd timer needs `AccuracySec=1s` — and even then, prefer `OnUnitActiveSec=1s` over `OnCalendar`.** `AccuracySec` defaults to **1 minute**, which is 60× too coarse to express this at all. `OnUnitActiveSec` also measures from the end of the previous run, so a slow job stretches the gap rather than stacking invocations.
• **Overlap is near-certain at this cadence.** If the job ever takes longer than one second, runs stack up and pile on. Prefer `fixedDelay` (waits for the previous run to finish) over `fixedRate`, or guard with an in-flight lock.
• In Spring, `* * * * * *` is the 6-field form (seconds first). The 5-field Unix `* * * * *` means every *minute* — the difference is one asterisk and 60× the frequency.
• In Quartz, use `* * * * * ?` — the `?` fills the unused day-of-week field, since Quartz forbids specifying both day-of-month and day-of-week.
• **A cron parser is real overhead at 1 Hz.** Re-evaluating an expression every second to decide "yes, now" is wasted work compared to `tokio::time::interval(Duration::from_secs(1))` or `setInterval(fn, 1000)`, which just sleep.
• Per-second cron is a strong signal you want a long-lived worker process, not a scheduler. If each firing spawns a process or container, the startup cost will dominate the actual work.

Frequently asked questions