Skip to content

Worker Runtime Betrieb

Typische operative Pruefungen

  • bestaetigen, dass der Tenant enabled ist
  • pruefen, ob die relevanten jobs.*.config.enabled-Flags aktiv sind
  • aktuelle Zeit gegen konfigurierte repeat_interval, repeat_interval_cold, plan_run oder Deep-Sync-Einstellungen halten
  • bei fehlenden UI-Updates pruefen, ob eine Upstream-Abhaengigkeit noch auf Packages wartet

Haeufige Laufzeitmuster

Situation Wahrscheinliche Erklaerung
Packages sichtbar, Payloads veraltet Payload-Loop blockiert, verzoegert oder nicht aktiviert
Messages veraltet, Alerts veraltet Package-Abhaengigkeit nicht erfuellt oder Message-Loop verzoegert
Alerts veraltet, Messages aktuell Alert-Loop verzoegert, deaktiviert oder durch Lock blockiert
Archive fehlen plan_run noch nicht erreicht oder Archivjob deaktiviert

Wichtige Scheduling-Beispiele

  • Archiv-Loop nutzt eine geplante Tageszeit wie 02:00
  • Packages-Loop kann mit repeat_interval=600 laufen
  • Payload-Loop kann repeat_interval=30 verwenden
  • Alerts-Loop kann repeat_interval=60 verwenden
  • Messages kombinieren schnelle und langsamere Intervalle ueber Hot- und Cold-Einstellungen

Das sind Beispiele aus aktuellen Codepfaden und Defaults, keine harte Plattformgarantie.

Warum Worker/Runtime haeufig die Wurzel ist

Viele Vorfaelle vom Typ "Daten fehlen in der UI" beginnen an einer dieser Stellen:

  • eine Schleife ist deaktiviert
  • ein Lock wurde nicht erhalten
  • eine Upstream-Abhaengigkeit ist noch nicht abgeschlossen
  • Runtime-Zeitstempel schieben den naechsten Lauf noch in die Zukunft