Understanding Joomla Scheduler Timeouts and Task Locks
QCTNH uses Joomla Scheduler’s configured timeout to distinguish a currently active lock from a lock old enough to be treated as stale/soft.
Timeout threshold
The snapshot reads the Scheduler component timeout parameter, with a default of 300 seconds and a floor of 60 seconds. It calculates a threshold of “now minus timeout.”
Lock classifications
| Condition | QCTNH interpretation |
|---|---|
Enabled task has locked newer than the threshold | Active/hard lock; Scheduler Health becomes Working when any active lock exists. |
Eligible web-runnable task has locked at or before the threshold | Soft/stale lock; Scheduler Health becomes Attention when there is no active lock. |
| No active/stale lock | Health can be Due or Healthy depending on due task count. |
Why QCTNH does not clear the lock
A stale timestamp is diagnostic evidence, not proof that deleting the lock is safe. QCTNH reports it and leaves repair to Joomla/administrator troubleshooting.
How this affects eligibility
The behavior in Understanding Joomla Scheduler Timeouts and Task Locks feeds QCTNH’s eligibility snapshot rather than bypassing Joomla. An ordinary web-runnable candidate must be enabled, not CLI-exclusive, have a non-null next execution time, and correspond to a task routine Joomla currently knows. Those filters prevent deleted/orphaned task types and CLI-only workloads from being advertised as work the WebCron path can perform.
When a task seems missing from QCTNH’s due/next-due view, inspect those eligibility conditions before changing service timing. Maximum Scheduler Delay cannot make an ineligible row executable.
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.