Every 45 Seconds

Type */45 * * * * * into any seconds-aware cron parser — including the widget above — and the problem shows up immediately: it fires at second :00 and second :45, then again at :00, :45. The gaps run 45 seconds, then 15, then 45, then 15. That isn’t “every 45 seconds.”

This interval is unusual in that it trips over two separate limitations at once.

Problem one: standard cron has no seconds

Before the step arithmetic even matters, plain Unix crontab is out. Its five fields start at minutes, so its floor is one minute — see sub-minute scheduling for which runtimes can go below that and what each one’s real minimum is. Kubernetes CronJob, AWS EventBridge and Cloudflare Workers all inherit the one-minute floor; GitHub Actions floors at five minutes.

So you need a 6-field, seconds-first dialect — Spring, Quartz, node-cron, APScheduler — just to get in the door.

Problem two: 45 doesn’t divide 60

Once you’re in a seconds-aware dialect, the same arithmetic that breaks every 45 minutes breaks this one unit down.

The seconds field runs 0–59. */45 means “start at 0, keep adding 45 while still in range”: second 0, second 45, then 90 — out of range, so it stops. At the top of the next minute the field resets and those same two values repeat. Cron matches fields against the wall clock; it has no memory of when it last ran, so it can’t carry a 45-second offset across the minute boundary.

Intervals like 15, 20 and 30 seconds divide the minute evenly, so their */n forms repeat cleanly. 45 leaves a remainder, so the schedule only closes over a 3-minute window — the least common multiple of 45 and 60 seconds.

The correct form: enumerate the 3-minute cycle

A true 45-second interval starting on the minute fires at 00:00, 00:45, 01:30, 02:15, then 03:00 where the cycle repeats. Each firing lands on a different second-of-minute, so you need four entries:

0  */3    * * * *    # second :00 at minutes 0,3,6,...,57
45 */3    * * * *    # second :45 at minutes 0,3,6,...,57
30 1-59/3 * * * *    # second :30 at minutes 1,4,7,...,58
15 2-59/3 * * * *    # second :15 at minutes 2,5,8,...,59

In Quartz idiom, using n/3 start-step syntax and ? for the unused day-of-week field:

0  0/3 * * * ?
45 0/3 * * * ?
30 1/3 * * * ?
15 2/3 * * * ?

This tiles cleanly. An hour is 3,600 seconds and the cycle is 180, so 3,600 ÷ 180 = 20 whole cycles per hour — 80 firings per hour, every gap exactly 45 seconds, including the wrap from the last firing at 59:15 to 00:00 of the next hour. Because the hour divides evenly, midnight needs no special handling either. Over a day that’s 1,920 runs, which is exactly 86,400 ÷ 45.

On Linux: the crontab form, and why systemd’s OnCalendar won’t help

Plain crontab has no seconds field, so the four entries above have to be expressed as minute schedules with sleep offsets carrying the seconds — four lines covering the same 3-minute cycle (full block in the Linux tab above).

The part worth knowing: systemd’s OnCalendar= cannot express this either. OnCalendar matches wall-clock fields exactly the way cron does, so it hits the identical non-divisor wall — there is no *:*:00/45 that yields a steady 45-second gap. Reaching for a systemd timer doesn’t rescue you here the way it does at 10 or 30 seconds.

What does work is the monotonic timer, which measures from the last run rather than against the clock:

[Timer]
OnUnitActiveSec=45s
AccuracySec=1s

AccuracySec still matters — it defaults to 1 minute, which would swamp a 45-second interval outright. See systemd timers.

The simpler answer: use a timer

Look at what the correct version costs: four schedule entries, each re-evaluated every second, to produce one firing every 45. And unlike every 45 minutes — where wall-clock alignment might genuinely matter — there is nothing meaningful to align to at a 45-second cadence. The runs walk around the minute face no matter what.

So express it as what it actually is, a polling interval:

• Spring — @Scheduled(fixedDelay = 45_000). Use fixedDelay, not fixedRate: it measures the gap from the end of the previous run, so a slow run can’t cause stacking. See the Spring @Scheduled guide.
• Rust — tokio::time::interval(Duration::from_secs(45)) in a loop. See Rust cron scheduling.
• Python — IntervalTrigger(seconds=45), which sidesteps CronTrigger’s field rules entirely. See the APScheduler guide.
• systemd — OnUnitActiveSec=45s, monotonic and DST-proof. Set AccuracySec=1s as well, or the default 1-minute accuracy window will swamp a 45-second interval completely. See systemd timers.

Reach for the four-entry cron cycle only when something downstream genuinely requires the firings to land on those specific clock seconds.