Cron at 0 * * * * fires every job on the same second. A thousand webhook-poll workers hammering upstream at :00:00 is a thundering herd. Paste your job IDs and pick a jitter window — each job gets a deterministic offset from a stable hash, so its fire time is the same every hour, retries hit the same slot, and the aggregate load flattens out.
| Job ID | Hash | Offset (s) | Fires at | Bar |
|---|
Random sleep(rand(0,window)) at the top of a handler does spread load, but it also makes every run start at a different second — you lose the guarantee that job tenant-42 always runs at :04:17. That matters when a run crashes and a supervisor retries it: you want the retry to hit the same bucket, not pile onto the already-crowded :00 spike. It also matters for observability — a stable offset makes dashboards, alerts, and log correlation actually mean something.
The formula is offset = hash(salt + job_id) mod window. The salt is optional but useful when the same job identifier is scheduled on two different queues — a different salt per queue lets each queue independently smooth its load without leaking any bucket-alignment between them.