What QCTNH Sends During Registration and Check-In
QCTNH service communication is limited to operational scheduler and installation data needed to register the native WebCron target and schedule useful wake-ups.
Initial registration payload
| Field group | Examples |
|---|---|
| Installation identity | Installation UUID, current origin, local service secret. |
| Native WebCron | Exact Joomla WebCron endpoint and WebCron key. |
| Versions/settings | Joomla version, QCTNH version, Maximum Scheduler Delay. |
| Scheduler timing | Next due timestamp, whether that timestamp is known, due-task count. |
Signed check-in/service-state payload
Later signed messages can include reason, scheduler health, next due, due count, hard/soft lock counts, WebCron readiness, service enabled state, and version/settings information. The purpose is to update the central schedule and service state, not to export site content.
What is not sent as part of this protocol
The current QCTNH payloads do not include article bodies, visitor browsing history, customer records, passwords, arbitrary database content, or the content of the Scheduled Tasks themselves. QCTNH communicates scheduler metadata and credentials required for the wake-up service.
Native WebCron remains the execution transport
Even when What QCTNH Sends During Registration and Check-In 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.