What Happens After a Joomla WebCron Request Completes

After a Joomla WebCron request completes, QCTNH tries to push the new scheduler snapshot outbound so QuantaCade can schedule the next useful wake-up from fresh state.

Post-WebCron behavior

The System plugin detects frontend requests where option=com_ajax, plugin=RunSchedulerWebcron, and group=system. If QCTNH is already registered, it calls checkin("webcron_complete").

What the check-in updates

The local snapshot includes health, next-due time/known flag, due count, hard/soft lock counts, service/WebCron state, settings, and version information. On successful contact, QCTNH updates the last QuantaCade contact timestamp.

Why registration probe avoids recursion

During the initial registration probe the local component has not yet received QuantaCade’s success response, so the plugin checks registered() before issuing the post-WebCron check-in. That avoids recursively trying to register from inside the registration probe itself.

Failure-safe scheduling

What Happens After a Joomla WebCron Request Completes also sits inside bounded retry rules. A busy/ambiguous timeout can receive a short continuation, more-due work can receive a quick follow-up, while a task failure backs off instead of hammering the same failing workload. Unknown timing eventually falls back to Maximum Scheduler Delay/safety checks.

These distinctions are why Recent Activity and task/HTTP result codes matter: the worker does not treat every unsuccessful response as the same reason to retry.

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.