Cron jitter: spread starts without changing business deadlines

Explain synchronized load

Many jobs scheduled at minute zero can spike shared databases or APIs at once. Spreading starts can reduce that peak.

First decide the allowed delay and the business completion deadline. Random delay is not automatically acceptable for every task.

Nominal schedule: 0 * * * *
Example allowed execution delay: 0–120 seconds
The hourly reporting interval remains unchanged.

Distinguish fixed staggering and jitter

Assigning different minute values creates fixed staggering. Adding a bounded delay after a trigger creates execution jitter.

Fixed offsets are reproducible; random jitter can vary on every run. Preserve the nominal scheduled instant for accounting and deduplication.

Check dialect extensions

Hashed fields such as H and scheduler-specific random-delay settings are not universal five-field syntax.

A preview library can support extensions the deployed scheduler lacks. Use explicit numeric offsets for portable fixtures and read the actual scheduler documentation.

Keep retries and overlap bounded

Jitter can help spread retries too, but excessive delay can push a task into its next interval. Runtime and backoff consume the same deadline budget.

Test worst-case delay plus runtime, and apply a concurrency policy if the budget exceeds the schedule spacing.