Why Maximum Scheduler Delay Is Not a Fixed Polling Interval

Maximum Scheduler Delay is deliberately not implemented as “call this site every N minutes.” QCTNH uses it only where a schedule-aware decision does not provide a better time.

Situations that override the nominal delay

• Known future next due: sleep until around that time.
• More work already due: follow quickly to drain the queue.
• Busy execution: continue in about 30 seconds.
• Task failure: back off at least five minutes.
• Idle/ran with no next due: use a six-hour safety recheck.

Where the delay matters

The selected value is a fallback for uncertain/retry timing and a bound used by the central scheduler. It also determines the worker’s retry time if a successful WebCron response occurs but the expected fresh outbound scheduler snapshot does not arrive.

Failure-safe scheduling

Why Maximum Scheduler Delay Is Not a Fixed Polling Interval also sits inside bounded retry rules. A busy/ambiguous timeout can receive a short continuation, more-due work can receive a quick follow-up, while a task failure backs off instead of hammering the same failing workload. Unknown timing eventually falls back to Maximum Scheduler Delay/safety checks.

These distinctions are why Recent Activity and task/HTTP result codes matter: the worker does not treat every unsuccessful response as the same reason to retry.

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.