How QCTNH Uses a Known Future next_due Time

When Joomla reports a future next-due time, QCTNH can schedule the next external wake-up around that task instead of polling continuously.

How a known future time is produced

The local snapshot finds the earliest next_execution among eligible web-runnable tasks and sends it as next_due with next_due_known=true.

Central scheduling rule

If the timestamp is in the future, the service schedules the next poll at approximately that due time plus a small random jitter of 0–30 seconds (bounded by the configured delay), while also enforcing a six-hour safety recheck ceiling.

Why jitter exists

A small random offset avoids creating an unnecessarily synchronized burst when many sites/tasks become due at an identical wall-clock time. It does not materially change the task schedule; Joomla remains the authority over the actual execution time and task selection.

Native WebCron remains the execution transport

Even when How QCTNH Uses a Known Future next_due Time involves QuantaCade-side scheduling logic, the final wake-up is still the exact validated Joomla WebCron route. The worker does not call a proprietary endpoint and then ask QCTNH to choose a task. That keeps queue selection, locking, and task execution inside Joomla.

Legacy QCTNH control endpoints may remain for compatibility, but they are not the normal production wake-up path documented for 2.0.3.

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.