Schedules
Ein Schedule definiert die On-Call-Rotation eines Teams — wer deckt sie ab, und wann — plus einmalige Overrides für Tausch und Abwesenheit.
Ein Schedule gehört zu genau einem Team und beantwortet eine Frage: Wer hat gerade jetzt Bereitschaft? Eine Eskalationsrichtlinien-Stufe kann direkt auf einen Schedule zielen, sodass „alarmiere, wer gerade Bereitschaft hat" ein Routing-Ziel erster Klasse ist — keine von Hand gepflegte Namensliste.
Die Rotation
Ein Schedule hat genau eine Rotation. Abdeckung wird nicht innerhalb eines Schedules gestapelt, sondern auf Ebene der Eskalationsstufe — eine Stufe kann mehrere Schedules ansprechen.
Eine Rotationsperiode setzt eine Gruppe von Mitgliedern gemeinsam auf Bereitschaft, als gleichrangige Peers: Sie schneiden einander nicht. Welcher von ihnen einen konkreten Vorfall tatsächlich erreicht, entscheidet sich beim Alarmieren, nicht hier.
Wie die Gruppe gebildet wird:
none— gar keine Übergabe. Alle im Schedule haben für dessen gesamten Gültigkeitszeitraum Bereitschaft, als eine durchgehende Schicht.auto— der Mitgliederpool wird automatisch in Gruppen der von dir angegebenen Größe aufgeteilt.explicit— du definierst die Gruppen und ihre Reihenfolge selbst.
Wie oft übergeben wird:
daily,weekly,biweekly,monthly— zur eingestellten Uhrzeit, am eingestellten Wochentag bzw. Tag des Monats.custom— alle Nminutes,hours,days,weeksodermonths.
Die kürzeste Schicht ist eine Minute, und Übergabezeiten sind bei jeder Kadenz minutengenau.
Kadenzen unterhalb eines Tages (minutes, hours) schreiten in absoluter Zeit voran statt nach Wanduhr. Eine Zeitumstellung verdoppelt oder überspringt dadurch keine Übergaben.
Unabhängig von der Rotation kann ein Schedule Wochenfenster tragen — wiederkehrende Uhrzeit-Fenster wie „werktags 09:00–18:00 Uhr" —, sodass reine Bürozeiten-Abdeckung keinen separaten Schedule braucht. Außerhalb dieser Fenster hat schlicht niemand Bereitschaft.
Materialisierung
Ein Hintergrund-Worker berechnet die Rotation jedes Schedules bis zu 90 Tage im Voraus zu konkreten Schicht-Zeilen vor. Das ist Absicht: Die Frage „wer hat gerade Bereitschaft" lässt sich im Moment der Eskalation dann als indizierte Zeitstempel-Abfrage beantworten statt als Live-Berechnung über Zeitzone und Sommerzeit — genau der Moment, in dem eine Abweichung von der Realität am wenigsten verzeihlich wäre, ist der, in dem jemand alarmiert wird.
Eine schnelle Kadenz wird weniger weit vorausberechnet, denn die Zeilenzahl ist Horizont geteilt durch Kadenz — eine Ein-Minuten-Rotation über 90 Tage wären 129.600 Schichten pro Mitglied. Ein solcher Schedule wird stattdessen rund 41 Stunden im Voraus gehalten und stündlich nachgefüllt. Das begrenzt, wie weit eine Vorschau reicht, nicht die Abdeckung: Die Alarmierung liest immer die gerade laufende Schicht.
Overrides
Ein Override ist ein einmaliges „X vertritt Y"-Zeitfenster zusätzlich zur regulären Rotation — ein Urlaubstausch oder eine Krankheitsvertretung, ohne die Rotation selbst zu bearbeiten. Overrides haben kein Prioritätsfeld: Der Vorrang zwischen überlappenden Overrides wird durch die Erstellungsreihenfolge entschieden (der zuletzt erstellte gewinnt) — in genau dieser Reihenfolge liest sie auch der Materializer.
Zeitzone
Jeder Schedule hat eine IANA-Zeitzone. Übergaben und Restriktions-Fenster werden in dieser Zone ausgewertet, auch über Sommerzeit-Umstellungen hinweg — eine Übergabe um 09:00 meint 09:00 Uhr in der eigenen Zone des Schedules, nicht UTC.
API
Siehe Schedules, Schedule-Overrides und Wer hat Bereitschaft.
Aufbewahrung (Retention)
Wie lange Incident Management rohe Alert-Payloads, gelöste Alerts und Outbound-Zustellprotokolle aufbewahrt — und was unbegrenzt erhalten bleibt.
Severity (Schweregrad)
Incident Management nutzt eine vierstufige Sev1-Sev4-Skala, die Alarmierungsdringlichkeit, Eskalationsgeschwindigkeit und die feuernde Benachrichtigungskette bestimmt.