How Schedule-Aware Polling Reduces Unnecessary Wake-Ups
QCTNH uses scheduler timing to avoid waking a site more often than useful. The service stores next-due state and calculates a next poll from current scheduler conditions.
Scheduling inputs
- Maximum Scheduler Delay (bounded to 5–60 minutes).
- Known future
next_duetimestamp. - Whether more work is already due.
- Worker result state such as busy, ran, task_failed, repaired, or idle.
- Six-hour safety recheck ceiling.
Examples
| State | Central behavior |
|---|---|
| Known future task | Schedule near the future due time with up to 30 seconds of jitter, but never later than the safety recheck. |
| More work due | Stored next poll can be about 5 seconds; within one worker run successful follow-ups can be about 2 seconds apart. |
| Busy/long-running | Retry around 30 seconds later. |
| Task failed | Back off at least five minutes or the configured Maximum Delay, whichever is longer. |
| Idle/ran with no known next due | Use the six-hour safety recheck. |
Result
The configured delay is a safety/fallback input rather than a fixed polling clock, reducing unnecessary external traffic on sites where Joomla can report precise future timing.
Identity and timing are both required
For How Schedule-Aware Polling Reduces Unnecessary Wake-Ups 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.