How Busy and More-Due Follow-Ups Stay Bounded
QCTNH intentionally caps busy/backlog continuation so one site cannot monopolize a worker indefinitely.
Current worker bounds
| Limit | 2.0.3 behavior |
|---|---|
| Worker deadline | Approximately 52 seconds for a worker run. |
| Initial batch | Up to 25 due sites selected for a cycle. |
| Per-site attempts | Maximum 12 attempts within the worker cycle. |
| Busy/resume delay | 30 seconds before a continuation attempt. |
| More-due delay | About 2 seconds inside the same worker run after a successful result. |
Fresh-state guard
Before a queued follow-up fires, the worker reloads the site row. If a same-server or remote post-run check-in has already scheduled the next poll safely in the future, the worker skips the unnecessary follow-up.
Failure stops tight looping
Task-failed and paused states do not receive immediate follow-up attempts, and transport/service errors use central failure/backoff handling instead of endless rapid retries.
Native WebCron remains the execution transport
Even when How Busy and More-Due Follow-Ups Stay Bounded involves QuantaCade-side scheduling logic, the final wake-up is still the exact validated Joomla WebCron route. The worker does not call a proprietary endpoint and then ask QCTNH to choose a task. That keeps queue selection, locking, and task execution inside Joomla.
Legacy QCTNH control endpoints may remain for compatibility, but they are not the normal production wake-up path documented for 2.0.3.
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.