How the Frontend Heartbeat Works and Why It Uses a Six-Hour Cadence

The frontend heartbeat is a lightweight same-site signal that can refresh QuantaCade scheduler timing during ordinary site traffic, but it is throttled to a six-hour cadence.

How it is triggered

On normal frontend HTML pages, when QCTNH is available and the service is enabled, the System plugin injects a small script just before </body>. About 1.2 seconds after page load, the browser POSTs a browser_heartbeat message to QCTNH’s Joomla AJAX endpoint using same-origin credentials.

Same-site protection

The endpoint compares the request Origin/Referer host with the current QCTNH site host. A cross-site browser request is rejected with “Same-site heartbeat required.”

Six-hour throttle

The local service checks last_heartbeat_at. If the last successful frontend heartbeat is less than 21,600 seconds (six hours) old, the call returns a throttled state instead of contacting QuantaCade again.

Why it exists

A heartbeat provides fresh schedule information when real traffic is available, complementing external wake-ups. It is not required for every page view and is not a visitor analytics mechanism.

Native WebCron remains the execution transport

Even when How the Frontend Heartbeat Works and Why It Uses a Six-Hour Cadence 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.