How QCTNH Handles Same-Server WebCron 403 Responses

When a direct WebCron call returns HTTP 403 and the Joomla site is on the same physical server as QuantaCade, the current production service has a narrowly scoped local CLI fallback; this is not the normal wake-up path.

Conditions

• The direct validated native WebCron request must specifically return HTTP 403.
• The target must resolve to the same physical server as the QuantaCade worker/service.
• The service must be able to identify the site’s local Joomla document root/CLI scheduler context.

What does not trigger fallback

Redirects, 401 authentication failures, 404 route failures, TLS/DNS errors, application success:false, and generic timeouts are not converted into a local run. That prevents the fallback from masking unrelated configuration/security problems.

Operational advice

Treat same-server fallback as resilience for a specific WAF/access-control edge case. Fix the 403 so the normal direct native WebCron architecture works and remains representative of how external customer sites are reached.

Architecture context

How QCTNH Handles Same-Server WebCron 403 Responses belongs to the 2.0.3 native-WebCron architecture. QCTNH’s local component/plugin produces scheduler state and authenticated check-ins; the central service stores the validated endpoint/credential and schedules work; the worker calls Joomla WebCron; Joomla selects and runs the task.

This separation is useful when reading reference behavior because not every value is owned by the same layer. Task recurrence/locks belong to Joomla, wake-up timing belongs to the service, and identity/origin protection spans the local and central registration state.

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.