Reading the Maximum Delay Metric

Maximum Delay is the administrator-selected QCTNH timing preference—5, 10, 15, 30, or 60 minutes—but it is not a promise that QuantaCade will hit the site on a fixed interval.

What the value controls

The value is sent during registration/check-ins and is used as a bounded fallback/retry cadence when exact task timing is not available or a fresh post-WebCron schedule was not received.

What can happen instead

  • If a future next_due time is known, QuantaCade can sleep until around that due time.
  • If more tasks are already due, follow-ups can occur within seconds to drain backlog.
  • If Joomla appears busy, the worker uses a roughly 30-second continuation.
  • If a task failed, polling backs off instead of hammering the failing task.
  • If there is no known work after an idle/ran state, a six-hour safety recheck may be used.

Interpret the card correctly

“Maximum Delay 10 min” means the service is allowed to use that configured delay in applicable fallback situations; it does not mean “poll every 10 minutes forever.”

What the setting cannot override

Reading the Maximum Delay Metric does not override Joomla task recurrence, task state, CLI exclusivity, locks, or extension-specific failures. QCTNH can change when an external wake-up is useful and can show the current scheduler condition, but Joomla still decides whether a task is eligible and what happens during execution.

If the Dashboard value looks correct yet a specific workload remains wrong, move the investigation to Joomla Scheduled Tasks and the owning extension rather than repeatedly changing QCTNH service settings.

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.