Troubleshooting Scheduled Task Failures Reported Through WebCron

When WebCron reaches Joomla successfully but the scheduler/task result reports failure, troubleshoot the owning Scheduled Task or extension rather than treating the event as a QCTNH transport failure.

Recognize a task failure

The central worker treats an HTTP 2xx response whose Joomla JSON says success:false as task_failed. HTTP 5xx is also classified as task failure/application/server failure rather than a healthy wake-up.

Investigate the task

  1. Open Joomla Scheduled Tasks and identify the task that was due/running.
  2. Inspect the owning extension’s logs/status/history for the same timestamp.
  3. Check Joomla/PHP server error logs for exceptions, memory exhaustion, timeouts, or permission failures.
  4. Fix the task-specific cause, then allow the next normal Scheduler run or execute it using the owning extension’s supported test/run workflow.

Why repeated wake-ups are bounded

After a task_failed result, QCTNH does not hammer the same failing task immediately; the central scheduler waits at least a more conservative delay before trying again.

Avoid destructive shortcuts

The guidance for Troubleshooting Scheduled Task Failures Reported Through WebCron does not require manually editing QCTNH identity, WebCron URL/key, scheduler locks, or next_execution in the database as a first response. QCTNH/Joomla already expose supported repair paths for registration, WebCron preparation, and task administration.

Direct database changes can break clone protection, hide credential drift, or allow overlapping tasks. Use them only as a separately planned recovery procedure with backups and clear source-level justification.

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.