Worker Runtime Operations
Typical operational checks
- confirm that the tenant is
enabled - inspect whether the relevant
jobs.*.config.enabledflags are true - compare current time against configured
repeat_interval,repeat_interval_cold,plan_run, or deep-sync settings - check whether a missing UI update is actually caused by an upstream dependency still waiting on packages
Common runtime patterns
| Situation | Likely explanation |
|---|---|
| packages visible, payloads stale | payload loop blocked, delayed, or not enabled |
| messages stale, alerts stale | package dependency not fulfilled or message loop delayed |
| alerts stale but messages current | alert loop delayed, disabled, or lock-blocked |
| archive missing | plan_run not reached yet or archive job disabled |
Important scheduling examples
- archive loop uses a planned daily time such as
02:00 - packages loop may use
repeat_interval=600 - payload loop may use
repeat_interval=30 - alerts loop may use
repeat_interval=60 - messages can combine fast and slower intervals through hot and cold settings
These are examples from current code paths and defaults, not hard platform invariants.
Why worker/runtime is a frequent root cause
Most "data is missing in the UI" incidents start in one of these places:
- a loop is disabled
- a lock was not acquired
- an upstream dependency has not completed
- runtime timestamps still place the next run in the future