A Go daemon starts 300 ticker loops at boot with the same interval, so every check fires together. How do you spread them?

## Phase and period A periodic loop has two properties. Its **period** is the interval you configured. Its **phase** is *where in that period its ticks land*, and it is decided entirely by the moment `time.NewTicker` was called. Nothing in Go's runtime staggers timers that share a duration; there is no automatic spreading. If you construct 300 tickers in a single `for` loop at process start, their creation times differ by microseconds, so their phases are effectively identical — and because a ticker's period is fixed, they stay identical for as long as the process lives. The visible result is a sawtooth: the daemon is idle for the whole interval, then does 300 renewal checks in one instant. Every downstream shared resource sees that shape — the certificate authority's rate limiter, the connection pool, the CPU. The average load is unchanged; the peak is 300 times what it needs to be. ## The fix is a random phase Delay each loop by a random fraction of one interval before its ticker exists: ```go for _, cert := range certs { go func() { time.Sleep(rand.N(interval)) // random phase, drawn once ticker := time.NewTicker(interval) defer ticker.Stop() watch(ctx, cert, ticker.C) }() } ``` `rand.N` comes from `math/rand/v2` and is generic over integer types, so it accepts a `time.Duration` directly and returns one in `[0, interval)`. Drawing each offset independently over a full interval gives an approximately uniform spread, and — this is the part people miss — it does **not** change any loop's rate. Each loop still runs exactly once per interval forever; only the alignment moved. `math/rand/v2` also does not need seeding: the global functions are randomly seeded per process, so two replicas of the same binary get different offsets without any work on your part. Since Go 1.22 the loop variable is per-iteration, so the closure capturing `cert` is correct as written; in older code the same loop needed the variable passed in as a parameter. ## Which random source Use `math/rand/v2`, not `crypto/rand`. Spreading load is not a security decision: nobody gains anything by predicting when your renewal check runs, and `crypto/rand` costs more and forces error handling for no benefit. Reaching for the cryptographic generator here is a small tell that a candidate applies rules rather than reasons about them. Deriving the offset from the clock instead — the nanosecond field of `time.Now`, say — defeats the purpose, because every loop that starts in the same instant reads nearly the same value. ## Bounding the jitter Jitter is delay, and delay eats safety margin. A renewal daemon renews when a certificate's `NotAfter` is inside a window — say thirty days out — precisely so that missing a few runs is harmless. Adding up to a full interval of extra delay at startup is fine when the interval is six hours and the window is thirty days. It is not fine if someone later shortens the window or lengthens the interval and the jitter budget quietly becomes the difference between renewing and expiring. Keep the jitter bounded by the interval, keep the safety margin an explicit multiple of the interval, and the two never collide. A common alternative is proportional jitter: run at `interval` but offset by ±10%, which spreads a fleet enough to flatten a spike without a full interval of startup delay. Either shape is defensible; what matters is that the jitter is bounded and expressed in terms of the interval. ## What jitter does not fix Jitter spreads a burst. It does nothing about a run that takes longer than its interval, nothing about a loop that never checks for cancellation, and nothing about a dependency that is simply too slow for the aggregate rate you are asking of it. If 300 checks per interval is more than the downstream can take *on average*, spreading them changes the shape of the load and not its volume; the answer there is fewer checks or a bounded worker pool doing them, not a different random distribution. ## A note on the alternative shape A single ticker fanning work out to 300 items — one loop, one tick, a bounded pool doing the 300 checks — sidesteps the alignment question entirely and is often the better design, because it gives you one place to bound concurrency and one place to measure the schedule. Per-item loops are worth their cost when the items have genuinely different intervals or lifetimes; when they do not, one loop plus a bounded fan-out is simpler and its load profile is something you control directly rather than something you sample from a distribution.