How Jitter and the Safety Recheck Affect Wake-Up Timing

Two timing safeguards reduce synchronized traffic and prevent a site from disappearing indefinitely from service scheduling: small jitter around known due times and a six-hour safety recheck.

Jitter

For a known future due time, the central scheduler adds a random 0–30 second offset, limited by the configured Maximum Delay. This spreads otherwise simultaneous wake-ups without changing Joomla’s actual task schedule.

Safety recheck

Each scheduling calculation establishes a safety time six hours in the future. A known future task cannot push the next service check beyond that ceiling, and an idle/ran site with no known future due time can use the safety time directly.

Why both are useful

Jitter protects the service from unnecessary thundering-herd behavior; the safety recheck protects against stale timing if a future schedule change or missed local check-in fails to reach QuantaCade.

Identity and timing are both required

For How Jitter and the Safety Recheck Affect Wake-Up Timing to work safely, QuantaCade needs both a valid registered identity/endpoint and useful scheduler timing. A perfectly known next-due time is not enough if the site origin or WebCron credential is invalid; a perfect connection is not enough to schedule intelligently if Joomla has no eligible task timing.

Test Connection focuses on identity/public reachability, while task-change/WebCron-completion check-ins keep operational timing current.

Community Discussion

Want to compare scheduler workflows, share practical tips, or discuss how you use this QCTNH feature? Visit the QC Task Nudge & Health Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.