What Happens When the Joomla WebCron Key Changes

If Joomla’s WebCron key changes, QCTNH treats the stored registration as out of sync until the new key is synchronized with QuantaCade.

Why QCTNH notices

Local registered state stores a SHA-256 hash of the WebCron key that was registered. QCTNH also reads the current System - Schedule Runner WebCron key. A mismatch means the worker’s stored credential may no longer authenticate to Joomla.

What can change the key

  • An administrator regenerates or edits the Joomla WebCron key.
  • A restore brings back a different Joomla plugin configuration.
  • Another tool modifies Schedule Runner parameters.
  • QCTNH creates a key because the restored/current plugin had none.

Recovery

  1. Run Check WebCron to ensure WebCron is enabled and a non-empty current key exists.
  2. Allow QCTNH’s WebCron synchronization path to register the current endpoint/key; saving Schedule Runner configuration also triggers synchronization through the system plugin.
  3. If Connected does not recover, run Test Connection and inspect Recent Activity for the exact sync/registration error.

Preserve clone protection while migrating

The rule behind What Happens When the Joomla WebCron Key Changes is intentionally conservative: a copied database is not permission to move the existing service identity to whatever hostname now serves that copy. Automatic activity preserves the registered origin and records a mismatch instead of rotating credentials.

Only an administrator-triggered Test Connection from the intended final canonical URL may confirm a true move. That explicit step protects the original site while still making legitimate migrations straightforward.

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.