Understanding WebCron Timeouts and Long-Running Scheduled Tasks

Long-running Joomla Scheduled Tasks can outlive an HTTP client’s immediate response window, so a WebCron timeout does not always mean the task never started or failed.

How the worker handles ambiguous timeout

When a direct WebCron request produces no HTTP status because it times out, the current worker can classify the site as busy and schedule a short continuation instead of immediately declaring the task application failed. A fresh outbound webcron_complete check-in can later provide updated scheduler state.

What the administrator should check

• Active Locks / Health Working after the request.
• Owning extension logs showing the task started or completed.
• PHP/FPM/proxy timeout settings versus the task’s expected runtime.
• Joomla Scheduler timeout used to distinguish active vs stale locks.

Do not simply raise every timeout

A task that routinely needs long processing may require CLI execution, chunking, or extension-specific tuning. Treat HTTP timeout behavior as an architectural signal, not only a number to increase.

Diagnose from the outside in

For Understanding WebCron Timeouts and Long-Running Scheduled Tasks, a reliable order is: local Joomla prerequisites → QCTNH WebCron readiness → public DNS/TLS/route → WebCron authentication → Joomla Scheduler/task result. Each layer produces different evidence, so skipping directly to reinstalling QCTNH often obscures the real cause.

Use Check WebCron for the local layer and Test Connection for the full public registration/probe layer. Then use Joomla/extension logs if the request succeeded but the task itself failed.

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.