Why QCTNH Never Forces a Specific Scheduled Task ID

QCTNH never appends a Scheduled Task ID to its registered WebCron target and never asks QuantaCade to invoke a specific extension routine.

Registration validation forbids task targeting

The central service accepts only the exact native Joomla WebCron route. Registration is rejected if the endpoint includes a hash or id parameter, and unexpected query parameters are rejected.

Execution time

When the worker wakes the site, it adds only Joomla’s WebCron hash key. Joomla Scheduler receives the request and chooses its next eligible task using Joomla’s own rules.

Why this design matters

• No QuantaCade-side task ordering logic can override Joomla.
• Extension task plugins are executed through Joomla’s normal scheduler lifecycle.
• QCTNH can remain generic across backup, mail, cleanup, sync, and other task types.

Timing consequence

The scheduler rule described in Why QCTNH Never Forces a Specific Scheduled Task ID also affects when QuantaCade should wake the site. QCTNH reports aggregate next_due, whether that value is known, and a due count. When an exact future time is known, the central service can sleep toward that point instead of generating fixed high-frequency traffic.

If timing is unknown, QCTNH falls back to the configured Maximum Scheduler Delay and safety rechecks. Therefore a timing problem should be diagnosed from the scheduler snapshot first, not by assuming the service is simply a cron request every N minutes.

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.